Use when reasoning about baseline application-security properties: threat modeling, trust boundaries, Saltzer and Schroeder design principles, input validation, authentication vs authorization, secrets handling, secure-by-default choices, least privilege, defense in depth, and OWASP vulnerability classes as recurring failure modes. Covers cross-cutting decisions about what is trusted, where validation belongs, where authn/authz checks live, and how to bound blast radius. Do NOT use for LLM-specific prompt injection or agent-tool authority (use prompt-injection-defense), OWASP-category deep code review (use owasp-security), vendor webhook mechanics (use webhook-integration), cryptographic primitive implementation or key-management mechanics (use vendor/KMS/library docs), compliance/legal artifacts, or the social/organizational side of security. Do NOT use for configure a specific SAST or dependency scanner (use the scanner docs, then owasp-security for review).
What it is: Security fundamentals are the design principles and threat-modeling habits that decide whether a system can safely handle data, identity, and authority under adversarial conditions.
Mental model: Start with assets, adversaries, trust boundaries, and privileged actions. Every mitigation should be traceable to what crosses a boundary, who controls each side, what can go wrong, and how much damage remains if the boundary fails.
Why it exists: Security added after the system works is expensive and incomplete. Designing security in early makes attacks harder, slower, easier to detect, and smaller in blast radius.
What it is NOT: It is not an OWASP deep audit, LLM prompt-injection architecture, vendor webhook mechanics, scanner configuration, cryptographic primitive implementation, or legal compliance workflow.
Adjacent concepts:owasp-security owns category-specific application-security review; prompt-injection-defense owns LLM instruction-channel threats; type-safety carries validated values after boundary parsing; api-design and http-semantics shape public interfaces; webhook-integration owns vendor webhook mechanics.
One-line analogy: Security fundamentals are like structural engineering for software: load-bearing decisions must be in the design before people move in.
Common misconception: A pile of controls is not the same as a security argument; controls matter only when they are placed at the right trust boundaries and fail safely.
Security Fundamentals
Coverage
The cross-cutting design principles, threat-modeling discipline, and recurring vulnerability classes that determine whether a system can safely handle data, identity, and authority under adversarial conditions. Covers the foundational discipline upstream of any specific vulnerability or tool: Shostack's four threat-modeling questions, Saltzer and Schroeder's eight design principles (1975), trust boundaries, the authentication/authorization distinction, input validation as a boundary discipline, defense in depth, least privilege, and the OWASP Top 10 as a working enumeration of recurring failure classes. Does NOT cover the implementation of specific cryptographic primitives, the configuration of specific scanners, the regulatory artifacts of compliance regimes, the LLM-specific specialization to prompt injection, or the organizational/social side of security.
Philosophy of the skill
Security is a property of the design, not a feature added after the system works. The cost of designing security in is small; the cost of retrofitting it is order-of-magnitude larger and produces worse results. The discipline of security fundamentals is the discipline of paying these costs early — at the threat-modeling stage, at the trust-boundary stage, at the authentication-design stage — before the system has accumulated the structural debt that makes retrofitting expensive.
The discipline does not promise prevention of attacks. Any non-trivial system will be attacked; some attacks will succeed. The goal is to make attacks expensive, slow, traceable, and limited in blast radius. Every design choice is evaluated by what it costs the defender vs what it costs the attacker. Secure-by-default choices cost the defender slightly more code upfront but cost the attacker a working exploit; opt-in security features cost the defender nothing upfront but cost the attacker very little when the developer inevitably forgets. The discipline is the deliberate placement of costs on the attacker rather than the defender.
For agents writing code, the discipline is what lets the agent reason about a security-relevant change without having to read the entire system. An agent that knows the trust boundaries, the authn/authz distinction, and the input-validation discipline can look at a new endpoint and ask: 'where is this endpoint receiving data from?' 'Is the data validated at the boundary?' 'Is authentication checked?' 'Is authorization checked at the moment of the privileged action?' 'What's the blast radius if any of these fail?' These questions produce the right code without the agent having to recall every OWASP entry.
The Four Threat-Modeling Questions (Shostack)
Question
What it produces
Common failure
What are we working on?
The system diagram, asset inventory, data classification, trust boundaries
Skipped; analysis proceeds against an unstated model
What can go wrong?
The threat list: STRIDE categories, attacker scenarios, abuse cases
Jumped to mitigation without enumerating threats
What are we going to do about it?
The mitigations: design choices, controls, monitoring
The bulk of effort goes here; without the first two, mitigations are random
Did we do a good job?
Verification: tests, reviews, ongoing monitoring
Declared without testing; threat model never revisited
A team that answers all four iteratively, with each system change, is doing security fundamentals. A team that answers only three, or answers them once, is doing security theater.
Saltzer & Schroeder's Eight Principles (1975)
These predate every modern technology and remain canonical because they describe properties, not implementations.
Principle
One-line gloss
What it forbids
Economy of mechanism
Keep it simple
Sprawling, complex security architectures with many components
Fail-safe defaults
Deny by default; permit by exception
"is_admin defaults to true" patterns
Complete mediation
Check every access; never cache "I checked this earlier"
First-request-only auth checks; trust-on-session
Open design
Don't depend on secrecy of the design (Kerckhoffs)
Security through obscurity; secret algorithms
Separation of privilege
Require multiple independent conditions for sensitive operations
Single-credential vault access for irreversible actions
Least privilege
Minimum permissions per entity
Service accounts with admin keys; over-scoped tokens
Least common mechanism
Minimize shared mechanism across users
Global state that leaks information between requests
Psychological acceptability
Security users will bypass is not security
Onerous policies that drive workarounds (sticky-note passwords)
The Authn / Authz Distinction
Concern
Question it answers
Verified by
Where it lives
When it runs
Authentication
"Who are you?"
Credentials (password, token, certificate, MFA)
Auth middleware, login flow
At session establishment
Authorization
"Are you allowed to do this?"
Policy against identity (RBAC, ABAC, ACLs)
At every privileged action
Every request to a protected resource
Conflating these is the #1 issue in the OWASP Top 10. The pattern: authenticate at the entry point; authorize at every privileged action. Never short-circuit authorization on the basis of having a valid session.
Input Validation As Boundary Discipline
The pattern, in order:
Define expectations. Every input has an explicit shape, range, and meaning expectation. Document it as a schema (Zod, JSON Schema, OpenAPI).
Validate at the boundary. Validation happens at the entry point of the request, not three function calls in. The earlier validation fails, the less the system has done with bad data.
Parse, don't validate (Alexis King). Convert the untrusted value into a typed, validated value once; trust the typed form everywhere downstream. This composes with type-safety — the type system carries the validation forward.
Treat validation failure as a response-shaped outcome. Return a structured error (400 Bad Request with field-level detail) rather than throwing in the middle of business logic.
Log validation failures. Repeated validation failures from a specific source may be probing for vulnerabilities; logged failures feed monitoring.
Boundary
Untrusted source
Validation discipline
User → application
HTTP request bodies, form inputs, query params, headers
The property of defense in depth is the composition — no single layer is the security; the security is what remains when one layer fails.
Verification
After applying this skill, verify:
A threat model exists for the system or feature, answering all four Shostack questions; it is dated and reviewed at meaningful intervals.
Trust boundaries are explicitly enumerated; each boundary has a validation discipline applied.
Authentication is required at every entry point that needs identity; authorization is checked at every privileged action — not just at session start.
Input validation happens at the trust boundary, returns structured errors, and is logged.
Sensitive data has been classified (public, internal, confidential, restricted, secrets); each tier has handling rules; secrets are never logged or stored unencrypted.
Service-to-service calls use mTLS or signed tokens; no service trusts another solely on network position.
Defaults are fail-safe (deny by default; permit by explicit exception with justification).
Every entity (user, service, process) has minimum-necessary permissions; service accounts do not have admin keys; tokens are scoped to the minimum action set.
Sensitive actions are logged with sufficient detail to reconstruct what happened; logs are protected from modification.
Monitoring is in place to detect anomalies and failed validations; alerts are tested.
Cryptographic primitives are implemented by well-reviewed libraries, not custom code; keys are managed (rotation, escrow, scoped access).
Compliance documentation (where applicable) is downstream of the security property, not a substitute for it.
Do NOT Use When
Instead of this skill
Use
Why
Defending an LLM agent against prompt injection
prompt-injection-defense
prompt-injection-defense owns the LLM-specific specialization; this skill is the broader framing
Implementation is library territory; this skill is upstream of "which primitive"
Webhook signature verification for a specific platform (Shopify, Stripe)
webhook-integration
webhook-integration owns vendor-specific patterns; this skill provides the framing
Social engineering, phishing, organizational security awareness
(no skill — out of scope)
Organizational security is a separate discipline
Penetration testing methodology
(no skill — out of scope)
A specialized professional discipline
Key Sources
Saltzer, J. H., & Schroeder, M. D. (1975). "The Protection of Information in Computer Systems". Proceedings of the IEEE, 63(9), 1278–1308. The foundational paper on security design principles; the eight principles articulated here remain canonical across every subsequent technology shift.
Shostack, A. (2014). Threat Modeling: Designing for Security. Wiley. The canonical modern reference on threat modeling, including the four-question framework and STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege).
OWASP. OWASP Top 10 (2021). The current stable awareness document for recurring web application vulnerability classes. Use owasp-security for OWASP-category deep review and newer Top 10 release-candidate mapping.
OWASP. Input Validation Cheat Sheet. Current practical guidance for validating untrusted input early and server-side.
Anderson, R. (2020). Security Engineering: A Guide to Building Dependable Distributed Systems (3rd ed.). Wiley. The comprehensive treatment of security engineering across cryptography, access control, authentication, and large-system architecture; the discipline's modern textbook.
Kerckhoffs, A. (1883). "La cryptographie militaire." Journal des sciences militaires, IX, 5–83. The foundational articulation of "security must not depend on the secrecy of the design" — the principle Saltzer & Schroeder generalized as "open design."
Lampson, B. W. (1973). "A Note on the Confinement Problem." Communications of the ACM, 16(10), 613–615. The foundational paper on confinement — the question of whether a program can be prevented from leaking information it has access to.
King, A. (2019). "Parse, don't validate". Modern articulation of the validation discipline: convert untrusted data to typed values once at the boundary, then trust the type.
Bell, D. E., & LaPadula, L. J. (1973). "Secure Computer Systems: Mathematical Foundations." MITRE technical report. The Bell-LaPadula model — foundational work on formal access-control models that underpin modern RBAC/ABAC systems.
Skill Graph context
Classification
Subject: quality-assurance
Public: true
Domain: quality/security
Scope: Teaching the portable design discipline behind secure applications: threat modeling, assets/adversaries/trust boundaries, Saltzer and Schroeder principles, input-validation placement, authentication vs authorization, secret classification, least privilege, secure defaults, defense in depth, and blast-radius reduction. Applies before and during feature/API/route/data-flow design when the question is whether a system can safely handle data, identity, and authority under hostile input and partial failure. Excludes OWASP-category deep code review (owasp-security), LLM-specific prompt/context/tool injection (prompt-injection-defense), vendor webhook signing/retry mechanics (webhook-integration), implementation of cryptographic primitives or KMS/envelope-encryption mechanics (vendor/library docs), legal/compliance artifacts, and organizational security training.
When to use
audit a route handler for authn, authz, and input validation
decide where to validate inbound data when the same shape comes in through multiple endpoints
decide whether a piece of data is a secret, a credential, or non-sensitive — and what handling each requires
produce a threat model for a new feature before any code is written
Triggers: is this secure, where should validation happen, authentication vs authorization, what could go wrong here, threat model, OWASP, do I need to check permissions here
Not for
implement HMAC verification for a Shopify webhook (use webhook-integration)
audit code against OWASP Top 10 categories (use owasp-security)
configure a specific SAST or dependency scanner (use the scanner docs, then owasp-security for review)
choose an envelope-encryption/KMS implementation for stored credentials (use vendor/KMS/library docs)
respond to a GDPR data-subject-access request (use legal/compliance docs)
defend an LLM agent against prompt injection (use prompt-injection-defense)
Analogy: Security fundamentals is to a software system what structural engineering is to a building — load-bearing walls, fire egress, electrical isolation, foundation depth are not features added after the building works; they are properties of the design from the first sketch, and retrofitting them costs ten times more and produces worse results than designing them in. A building that survives an earthquake does so because of decisions made at the structural-engineering stage, not because of decorations added later.
Common misconception: |
Grounding
Mode: universal
Truth sources: https://www.cs.virginia.edu/~evans/cs551/saltzer/, https://owasp.org/Top10/2021/, https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html, https://pages.nist.gov/800-63-4/sp800-63b.html, https://www.cisa.gov/sites/default/files/2023-06/principles_approaches_for_security-by-design-default_508c.pdf, https://owasp.org/www-project-top-10-for-large-language-model-applications/
Keywords
security fundamentals, threat modeling, input validation, authentication, authorization, authn, authz, least privilege, defense in depth, secure by default
1---2name: security-fundamentals3description: Use when reasoning about baseline application-security properties: threat modeling, trust boundaries, Saltzer and Schroeder design principles, input validation, authentication vs authorization, secrets handling, secure-by-default choices, least privilege, defense in depth, and OWASP vulnerability classes as recurring failure modes. Covers cross-cutting decisions about what is trusted, where validation belongs, where authn/authz checks live, and how to bound blast radius. Do NOT use for LLM-specific prompt injection or agent-tool authority (use prompt-injection-defense), OWASP-category deep code review (use owasp-security), vendor webhook mechanics (use webhook-integration), cryptographic primitive implementation or key-management mechanics (use vendor/KMS/library docs), compliance/legal artifacts, or the social/organizational side of security. Do NOT use for configure a specific SAST or dependency scanner (use the scanner docs, then owasp-security for review).4license: MIT5---6## Concept of the skill78**What it is:** Security fundamentals are the design principles and threat-modeling habits that decide whether a system can safely handle data, identity, and authority under adversarial conditions.910**Mental model:** Start with assets, adversaries, trust boundaries, and privileged actions. Every mitigation should be traceable to what crosses a boundary, who controls each side, what can go wrong, and how much damage remains if the boundary fails.1112**Why it exists:** Security added after the system works is expensive and incomplete. Designing security in early makes attacks harder, slower, easier to detect, and smaller in blast radius.1314**What it is NOT:** It is not an OWASP deep audit, LLM prompt-injection architecture, vendor webhook mechanics, scanner configuration, cryptographic primitive implementation, or legal compliance workflow.1516**Adjacent concepts:** `owasp-security` owns category-specific application-security review; `prompt-injection-defense` owns LLM instruction-channel threats; `type-safety` carries validated values after boundary parsing; `api-design` and `http-semantics` shape public interfaces; `webhook-integration` owns vendor webhook mechanics.1718**One-line analogy:** Security fundamentals are like structural engineering for software: load-bearing decisions must be in the design before people move in.1920**Common misconception:** A pile of controls is not the same as a security argument; controls matter only when they are placed at the right trust boundaries and fail safely.2122# Security Fundamentals2324## Coverage2526The cross-cutting design principles, threat-modeling discipline, and recurring vulnerability classes that determine whether a system can safely handle data, identity, and authority under adversarial conditions. Covers the foundational discipline upstream of any specific vulnerability or tool: Shostack's four threat-modeling questions, Saltzer and Schroeder's eight design principles (1975), trust boundaries, the authentication/authorization distinction, input validation as a boundary discipline, defense in depth, least privilege, and the OWASP Top 10 as a working enumeration of recurring failure classes. Does NOT cover the implementation of specific cryptographic primitives, the configuration of specific scanners, the regulatory artifacts of compliance regimes, the LLM-specific specialization to prompt injection, or the organizational/social side of security.2728## Philosophy of the skill29Security is a property of the design, not a feature added after the system works. The cost of designing security in is small; the cost of retrofitting it is order-of-magnitude larger and produces worse results. The discipline of security fundamentals is the discipline of paying these costs early — at the threat-modeling stage, at the trust-boundary stage, at the authentication-design stage — before the system has accumulated the structural debt that makes retrofitting expensive.3031The discipline does not promise prevention of attacks. Any non-trivial system will be attacked; some attacks will succeed. The goal is to make attacks expensive, slow, traceable, and limited in blast radius. Every design choice is evaluated by what it costs the defender vs what it costs the attacker. Secure-by-default choices cost the defender slightly more code upfront but cost the attacker a working exploit; opt-in security features cost the defender nothing upfront but cost the attacker very little when the developer inevitably forgets. The discipline is the deliberate placement of costs on the attacker rather than the defender.3233For agents writing code, the discipline is what lets the agent reason about a security-relevant change without having to read the entire system. An agent that knows the trust boundaries, the authn/authz distinction, and the input-validation discipline can look at a new endpoint and ask: 'where is this endpoint receiving data from?' 'Is the data validated at the boundary?' 'Is authentication checked?' 'Is authorization checked at the moment of the privileged action?' 'What's the blast radius if any of these fail?' These questions produce the right code without the agent having to recall every OWASP entry.3435## The Four Threat-Modeling Questions (Shostack)3637| Question | What it produces | Common failure |38|---|---|---|39| **What are we working on?** | The system diagram, asset inventory, data classification, trust boundaries | Skipped; analysis proceeds against an unstated model |40| **What can go wrong?** | The threat list: STRIDE categories, attacker scenarios, abuse cases | Jumped to mitigation without enumerating threats |41| **What are we going to do about it?** | The mitigations: design choices, controls, monitoring | The bulk of effort goes here; without the first two, mitigations are random |42| **Did we do a good job?** | Verification: tests, reviews, ongoing monitoring | Declared without testing; threat model never revisited |4344A team that answers all four iteratively, with each system change, is doing security fundamentals. A team that answers only three, or answers them once, is doing security theater.4546## Saltzer & Schroeder's Eight Principles (1975)4748These predate every modern technology and remain canonical because they describe properties, not implementations.4950| Principle | One-line gloss | What it forbids |51|---|---|---|52| **Economy of mechanism** | Keep it simple | Sprawling, complex security architectures with many components |53| **Fail-safe defaults** | Deny by default; permit by exception | "is_admin defaults to true" patterns |54| **Complete mediation** | Check every access; never cache "I checked this earlier" | First-request-only auth checks; trust-on-session |55| **Open design** | Don't depend on secrecy of the design (Kerckhoffs) | Security through obscurity; secret algorithms |56| **Separation of privilege** | Require multiple independent conditions for sensitive operations | Single-credential vault access for irreversible actions |57| **Least privilege** | Minimum permissions per entity | Service accounts with admin keys; over-scoped tokens |58| **Least common mechanism** | Minimize shared mechanism across users | Global state that leaks information between requests |59| **Psychological acceptability** | Security users will bypass is not security | Onerous policies that drive workarounds (sticky-note passwords) |6061## The Authn / Authz Distinction6263| Concern | Question it answers | Verified by | Where it lives | When it runs |64|---|---|---|---|---|65| **Authentication** | "Who are you?" | Credentials (password, token, certificate, MFA) | Auth middleware, login flow | At session establishment |66| **Authorization** | "Are you allowed to do this?" | Policy against identity (RBAC, ABAC, ACLs) | At every privileged action | Every request to a protected resource |6768Conflating these is the #1 issue in the OWASP Top 10. The pattern: authenticate at the entry point; authorize at every privileged action. Never short-circuit authorization on the basis of having a valid session.6970## Input Validation As Boundary Discipline7172The pattern, in order:73741. **Define expectations.** Every input has an explicit shape, range, and meaning expectation. Document it as a schema (Zod, JSON Schema, OpenAPI).752. **Validate at the boundary.** Validation happens at the entry point of the request, not three function calls in. The earlier validation fails, the less the system has done with bad data.763. **Parse, don't validate (Alexis King).** Convert the untrusted value into a typed, validated value once; trust the typed form everywhere downstream. This composes with `type-safety` — the type system carries the validation forward.774. **Treat validation failure as a response-shaped outcome.** Return a structured error (400 Bad Request with field-level detail) rather than throwing in the middle of business logic.785. **Log validation failures.** Repeated validation failures from a specific source may be probing for vulnerabilities; logged failures feed monitoring.7980| Boundary | Untrusted source | Validation discipline |81|---|---|---|82| User → application | HTTP request bodies, form inputs, query params, headers | Schema-based parsing at the entry point |83| External API → application | Webhook payloads, third-party responses, OAuth callbacks | Signature verification + schema validation |84| Database → application | (Trust your DB, but validate cross-tenant) | Org-scoped queries; row-level security |85| Client → server (API) | API requests | Schema validation + authn + authz |86| Process boundary (microservices) | Inter-service calls | mTLS or signed tokens + schema validation |87| Untrusted file → application | Uploaded files | Type detection, size limits, sandbox parsing |88| LLM → application (tool calls) | Tool arguments produced by LLM | Treat as untrusted; validate against tool schema |8990## Defense In Depth — Layered Controls9192| Layer | Purpose | Failure mode when missing |93|---|---|---|94| **Network** | Firewall, segmentation, WAF | Direct exposure of internal services to internet |95| **Identity** | Authn, MFA, SSO | Credential stuffing, account takeover |96| **Application authz** | RBAC/ABAC, per-action checks | Broken access control (OWASP A01) |97| **Input validation** | Schema parse, sanitize | Injection (OWASP A03) |98| **Data encryption** | At-rest, in-transit, end-to-end | Cryptographic failure (OWASP A02) |99| **Output encoding** | Escape on output (XSS, log forging) | XSS, log poisoning |100| **Rate limiting** | Throttling, anomaly detection | Brute force, scraping, DoS |101| **Logging & monitoring** | Audit trails, alerts | Undetected breach (OWASP A09) |102| **Incident response** | Playbooks, forensics, recovery | Slow response when attacks succeed |103104The property of defense in depth is the *composition* — no single layer is the security; the security is what remains when one layer fails.105106## Verification107108After applying this skill, verify:109- [ ] A threat model exists for the system or feature, answering all four Shostack questions; it is dated and reviewed at meaningful intervals.110- [ ] Trust boundaries are explicitly enumerated; each boundary has a validation discipline applied.111- [ ] Authentication is required at every entry point that needs identity; authorization is checked at every privileged action — not just at session start.112- [ ] Input validation happens at the trust boundary, returns structured errors, and is logged.113- [ ] Sensitive data has been classified (public, internal, confidential, restricted, secrets); each tier has handling rules; secrets are never logged or stored unencrypted.114- [ ] Service-to-service calls use mTLS or signed tokens; no service trusts another solely on network position.115- [ ] Defaults are fail-safe (deny by default; permit by explicit exception with justification).116- [ ] Every entity (user, service, process) has minimum-necessary permissions; service accounts do not have admin keys; tokens are scoped to the minimum action set.117- [ ] Sensitive actions are logged with sufficient detail to reconstruct what happened; logs are protected from modification.118- [ ] Monitoring is in place to detect anomalies and failed validations; alerts are tested.119- [ ] Cryptographic primitives are implemented by well-reviewed libraries, not custom code; keys are managed (rotation, escrow, scoped access).120- [ ] Compliance documentation (where applicable) is downstream of the security property, not a substitute for it.121122## Do NOT Use When123124| Instead of this skill | Use | Why |125|---|---|---|126| Defending an LLM agent against prompt injection | `prompt-injection-defense` | prompt-injection-defense owns the LLM-specific specialization; this skill is the broader framing |127| Encrypting stored credentials (envelope encryption, KMS) | Vendor/KMS/library docs, then `owasp-security` for review | implementation mechanics are outside this active skill library; this skill owns deciding what counts as a secret |128| OWASP-category code audit or vulnerability triage | `owasp-security` | owasp-security owns category-specific security review; this skill owns the upstream design principles |129| Choosing and configuring a SAST/DAST/dependency scanner | Scanner/vendor docs, then `owasp-security` for review | scanner setup is tooling-specific; this skill owns why the scan exists |130| GDPR / data-subject rights / regulatory artifacts | Legal/compliance docs | compliance workflow is outside this active skill library; this skill owns the underlying security design properties |131| Implementing a specific cryptographic primitive (AES, RSA, hashing) | Well-reviewed crypto library docs (libsodium, BouncyCastle, native APIs) | Implementation is library territory; this skill is upstream of "which primitive" |132| Webhook signature verification for a specific platform (Shopify, Stripe) | `webhook-integration` | webhook-integration owns vendor-specific patterns; this skill provides the framing |133| Social engineering, phishing, organizational security awareness | (no skill — out of scope) | Organizational security is a separate discipline |134| Penetration testing methodology | (no skill — out of scope) | A specialized professional discipline |135136## Key Sources137138- Saltzer, J. H., & Schroeder, M. D. (1975). ["The Protection of Information in Computer Systems"](https://www.cs.virginia.edu/~evans/cs551/saltzer/). *Proceedings of the IEEE, 63*(9), 1278–1308. The foundational paper on security design principles; the eight principles articulated here remain canonical across every subsequent technology shift.139- Shostack, A. (2014). *Threat Modeling: Designing for Security*. Wiley. The canonical modern reference on threat modeling, including the four-question framework and STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege).140- OWASP. [OWASP Top 10 (2021)](https://owasp.org/Top10/2021/). The current stable awareness document for recurring web application vulnerability classes. Use `owasp-security` for OWASP-category deep review and newer Top 10 release-candidate mapping.141- OWASP. [OWASP Top 10 for Large Language Model Applications](https://owasp.org/www-project-top-10-for-large-language-model-applications/). The LLM-specific specialization, including prompt injection and excessive agency; use `prompt-injection-defense` for that territory.142- OWASP. [Input Validation Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html). Current practical guidance for validating untrusted input early and server-side.143- Anderson, R. (2020). *Security Engineering: A Guide to Building Dependable Distributed Systems* (3rd ed.). Wiley. The comprehensive treatment of security engineering across cryptography, access control, authentication, and large-system architecture; the discipline's modern textbook.144- Kerckhoffs, A. (1883). "La cryptographie militaire." *Journal des sciences militaires*, IX, 5–83. The foundational articulation of "security must not depend on the secrecy of the design" — the principle Saltzer & Schroeder generalized as "open design."145- NIST. [Special Publication 800-63B-4: Digital Identity Guidelines — Authentication and Lifecycle Management](https://pages.nist.gov/800-63-4/sp800-63b.html). The current reference standard for authentication and lifecycle guidance.146- CISA et al. [Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software](https://www.cisa.gov/sites/default/files/2023-06/principles_approaches_for_security-by-design-default_508c.pdf). Secure-by-design and secure-by-default principles for software manufacturers.147- Lampson, B. W. (1973). "A Note on the Confinement Problem." *Communications of the ACM, 16*(10), 613–615. The foundational paper on confinement — the question of whether a program can be prevented from leaking information it has access to.148- King, A. (2019). ["Parse, don't validate"](https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/). Modern articulation of the validation discipline: convert untrusted data to typed values once at the boundary, then trust the type.149- Bell, D. E., & LaPadula, L. J. (1973). "Secure Computer Systems: Mathematical Foundations." MITRE technical report. The Bell-LaPadula model — foundational work on formal access-control models that underpin modern RBAC/ABAC systems.150151## Skill Graph context152153<!-- skill-graph-context:start (generated — do not edit by hand) -->154155**Classification**156- Subject: `quality-assurance`157- Public: `true`158- Domain: `quality/security`159- Scope: Teaching the portable design discipline behind secure applications: threat modeling, assets/adversaries/trust boundaries, Saltzer and Schroeder principles, input-validation placement, authentication vs authorization, secret classification, least privilege, secure defaults, defense in depth, and blast-radius reduction. Applies before and during feature/API/route/data-flow design when the question is whether a system can safely handle data, identity, and authority under hostile input and partial failure. Excludes OWASP-category deep code review (owasp-security), LLM-specific prompt/context/tool injection (prompt-injection-defense), vendor webhook signing/retry mechanics (webhook-integration), implementation of cryptographic primitives or KMS/envelope-encryption mechanics (vendor/library docs), legal/compliance artifacts, and organizational security training.160161**When to use**162- audit a route handler for authn, authz, and input validation163- decide where to validate inbound data when the same shape comes in through multiple endpoints164- decide whether a piece of data is a secret, a credential, or non-sensitive — and what handling each requires165- produce a threat model for a new feature before any code is written166- Triggers: `is this secure`, `where should validation happen`, `authentication vs authorization`, `what could go wrong here`, `threat model`, `OWASP`, `do I need to check permissions here`167168**Not for**169- implement HMAC verification for a Shopify webhook (use webhook-integration)170- audit code against OWASP Top 10 categories (use owasp-security)171- configure a specific SAST or dependency scanner (use the scanner docs, then owasp-security for review)172- choose an envelope-encryption/KMS implementation for stored credentials (use vendor/KMS/library docs)173- respond to a GDPR data-subject-access request (use legal/compliance docs)174- defend an LLM agent against prompt injection (use prompt-injection-defense)175176**Related skills**177- Verify with: `owasp-security`, `type-safety`, `api-design`, `prompt-injection-defense`178- Related: `webhook-integration`, `code-review`, `http-semantics`, `error-tracking`, `guardrails`, `owasp-security`, `type-safety`, `api-design`, `prompt-injection-defense`179180**Concept**181- Mental model: |182- Purpose: |183- Boundary: |184- Analogy: Security fundamentals is to a software system what structural engineering is to a building — load-bearing walls, fire egress, electrical isolation, foundation depth are not features added after the building works; they are properties of the design from the first sketch, and retrofitting them costs ten times more and produces worse results than designing them in. A building that survives an earthquake does so because of decisions made at the structural-engineering stage, not because of decorations added later.185- Common misconception: |186187**Grounding**188- Mode: `universal`189- Truth sources: `https://www.cs.virginia.edu/~evans/cs551/saltzer/`, `https://owasp.org/Top10/2021/`, `https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html`, `https://pages.nist.gov/800-63-4/sp800-63b.html`, `https://www.cisa.gov/sites/default/files/2023-06/principles_approaches_for_security-by-design-default_508c.pdf`, `https://owasp.org/www-project-top-10-for-large-language-model-applications/`190191**Keywords**192- `security fundamentals`, `threat modeling`, `input validation`, `authentication`, `authorization`, `authn`, `authz`, `least privilege`, `defense in depth`, `secure by default`193194<!-- skill-graph-context:end -->
Run npx skillmds@latest add jacob-balslev/security-fundamentals in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.
Use when reasoning about baseline application-security properties: threat modeling, trust boundaries, Saltzer and Schroeder design principles, input validation, authentication vs authorization, secrets handling, secure-by-default choices, least privilege, defense in depth, and OWASP vulnerability classes as recurring failure modes. Covers cross-cutting decisions about what is trusted, where validation belongs, where authn/authz checks live, and how to bound blast radius. Do NOT use for LLM-specific prompt injection or agent-tool authority (use prompt-injection-defense), OWASP-category deep code review (use owasp-security), vendor webhook mechanics (use webhook-integration), cryptographic primitive implementation or key-management mechanics (use vendor/KMS/library docs), compliance/legal artifacts, or the social/organizational side of security. Do NOT use for configure a specific SAST or dependency scanner (use the scanner docs, then owasp-security for review). It is listed under AI & ML on SkillMD.
This skill has not completed SkillMD's automated safety review yet. Capability flags: makes network calls, reads secrets. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.
This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.
Yes. Installing skills from SkillMD is free. This skill is licensed under MIT.
jacob-balslev (@jacob-balslev) published this skill. Their other Agent Skills are listed on their SkillMD profile.
jacob-balslev