security-architecture-review
Reviews a design or change for security before it ships — authentication and authorization, data handling, secrets, dependencies, and the secure-development practices around it. Use this to review an architecture or pull request for security, set secure coding standards, choose o
Install
npx skills add https://github.com/cbrock84/headcount/tree/main/plugins/security/skills/security-architecture-review
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install cbrock84-headcount@llmmart
git clone https://github.com/cbrock84/headcount.git
The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole cbrock84/headcount collection as a plugin from our marketplace. Git is the plain clone.
Skill manifest
Security architecture review
Review in this order
Attention spent in this order finds the most consequential problems first.
1. Authentication. How identity is established, how sessions are represented, how they expire, what happens on password reset and account recovery. Recovery flows are the most commonly weakest path into an account and the least reviewed.
2. Authorization. The one that matters most and gets least attention. For every endpoint and every object: who is allowed, and where is that checked? The characteristic failure is checking on the way in but not on the object itself, so any authenticated user can reach any record by changing an identifier.
Check multi-tenant isolation explicitly and by test, not by reading. Assume every identifier in a request is attacker-controlled, because it is.
3. Data. What is collected, where it goes, where it rests, and who can read it. Sensitive data in logs, in error responses, in analytics payloads, and in client bundles — all four are routine findings.
4. Input and output. Untrusted input reaching a query, a template, a command, a deserializer, or a URL the server fetches. Parameterize rather than escape. Validate against an allowlist rather than a denylist.
5. Secrets. Never in source, never in client bundles, never in build logs. Rotatable, scoped to what needs them, and with a documented rotation path that someone has actually walked.
6. Dependencies and supply chain. What is pulled in, how it is pinned, how updates are reviewed, and what would happen if a maintainer account were compromised. Lockfiles committed, builds reproducible.
Reviewing a change rather than a design
Look for: new endpoints without an authorization check, new external input, changed authentication or session logic, new dependencies, anything touching cryptography, and anything that widens what a role can do. Everything else is usually lower yield.
Never write your own cryptography. Use the vetted primitives, and be suspicious of any diff that implements a comparison, a token, or a signature by hand.
Sources
references/sources.md in this skill lists the outside authorities that settle the questions
here — what each one is authoritative for, and what you may do with it. Check them before
answering on anything they cover, and cite what you used. Most are free to read and not free
to reproduce; the use note on each is binding.
Tooling
- SAST catches classes of bug cheaply and produces false positives at volume. Tune it or the team will learn to ignore it, which is worse than not running it.
- DAST and dependency scanning find different things; neither replaces review.
- Secret scanning in CI and pre-commit is the highest-value automation per unit of effort.
By name today: Semgrep, CodeQL, or SonarQube for SAST; Snyk, Dependabot, or Trivy for dependencies; Burp Suite or OWASP ZAP for DAST; gitleaks, TruffleHog, or GitHub secret scanning for secrets — and similar in each category.
Automation is a floor, not a review. It finds known patterns, not design flaws — and design flaws are what actually cause the expensive incidents.
Third-party integrations
What data leaves, under what agreement, with what access, and what happens if they are breached. Scope credentials to the minimum, prefer short-lived tokens, and know how to revoke without an outage.
Never
- Approve a design on the promise of a control with no named owner and no date.
- Accept "it is internal" as an authorization boundary.
- Review the diagram instead of the change. Read what is actually being built.
- Sign off on a third-party integration without knowing what data leaves and under what terms.
Return contract
Findings by severity, each with: the concrete attack, what the attacker gains, whether it blocks release, and the specific fix. A finding with no attack path stated is a preference.
Files (headcount)
-
references
-
sources.md 2.7 KB
# Sources — `security:security-architecture-review` <!-- Generated by scripts/build-sources.py from sources/*.toml. Do not edit. --> Check these before answering on anything they cover, and cite what you used. The use note on each one is binding: most of what a professional cites is free to read and not free to reproduce. ## FedRAMP baselines and automation content GSA · US · public domain (US government) — quote freely <https://www.fedramp.gov/rev5/documents-templates/> Machine-readable: <https://github.com/GSA/fedramp-automation> **Authoritative for:** Which SP 800-53 controls apply at low, moderate and high impact for a cloud service selling to the US federal government, and the evidence each requires. ## MITRE ATT&CK The MITRE Corporation · global · free to use with attribution — credit the publisher <https://attack.mitre.org/> Machine-readable: <https://github.com/mitre-attack/attack-stix-data> **Authoritative for:** The shared vocabulary for adversary tactics and techniques — what to name a behavior so a detection, a threat model and an incident report refer to the same thing. ## NIST Cybersecurity Framework 2.0 NIST · US · public domain (US government) — quote freely <https://www.nist.gov/cyberframework> **Authoritative for:** The outcome-based vocabulary — govern, identify, protect, detect, respond, recover — that boards and customers most often ask a security program to map to. ## NIST SP 800-53 Rev. 5 — Security and Privacy Controls for Information Systems NIST · US · public domain (US government) — quote freely <https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final> Machine-readable: <https://github.com/usnistgov/oscal-content> **Authoritative for:** The control catalog US federal systems are assessed against, and the control vocabulary FedRAMP and many private frameworks inherit. ## OWASP Application Security Verification Standard OWASP Foundation · global · CC BY-SA — quote with attribution; share-alike, so do not fold into this repository <https://owasp.org/ASVS/> **Authoritative for:** Testable application security requirements at three assurance levels — the thing to write into a spec when 'make it secure' needs to become acceptance criteria. ## OWASP Top 10 OWASP Foundation · global · CC BY-SA — quote with attribution; share-alike, so do not fold into this repository <https://owasp.org/www-project-top-ten/> **Authoritative for:** The application-security risk categories a customer questionnaire or a pen-test report will be organized around. --- Sources are maintained in `sources/` upstream, not here. If one is wrong, out of date, or missing, fix it there — this file is regenerated and an edit to it is lost.
-
-
SKILL.md 4.3 KB
--- name: security-architecture-review description: Reviews a design or change for security before it ships — authentication and authorization, data handling, secrets, dependencies, and the secure-development practices around it. Use this to review an architecture or pull request for security, set secure coding standards, choose or tune SAST and DAST tooling, assess a third-party integration, or decide whether a design is safe to build. --- # Security architecture review ## Review in this order Attention spent in this order finds the most consequential problems first. **1. Authentication.** How identity is established, how sessions are represented, how they expire, what happens on password reset and account recovery. Recovery flows are the most commonly weakest path into an account and the least reviewed. **2. Authorization.** The one that matters most and gets least attention. For every endpoint and every object: who is allowed, and where is that checked? The characteristic failure is checking on the way in but not on the object itself, so any authenticated user can reach any record by changing an identifier. Check multi-tenant isolation explicitly and by test, not by reading. Assume every identifier in a request is attacker-controlled, because it is. **3. Data.** What is collected, where it goes, where it rests, and who can read it. Sensitive data in logs, in error responses, in analytics payloads, and in client bundles — all four are routine findings. **4. Input and output.** Untrusted input reaching a query, a template, a command, a deserializer, or a URL the server fetches. Parameterize rather than escape. Validate against an allowlist rather than a denylist. **5. Secrets.** Never in source, never in client bundles, never in build logs. Rotatable, scoped to what needs them, and with a documented rotation path that someone has actually walked. **6. Dependencies and supply chain.** What is pulled in, how it is pinned, how updates are reviewed, and what would happen if a maintainer account were compromised. Lockfiles committed, builds reproducible. ## Reviewing a change rather than a design Look for: new endpoints without an authorization check, new external input, changed authentication or session logic, new dependencies, anything touching cryptography, and anything that widens what a role can do. Everything else is usually lower yield. **Never write your own cryptography.** Use the vetted primitives, and be suspicious of any diff that implements a comparison, a token, or a signature by hand. ## Sources `references/sources.md` in this skill lists the outside authorities that settle the questions here — what each one is authoritative for, and what you may do with it. Check them before answering on anything they cover, and cite what you used. Most are free to read and not free to reproduce; the use note on each is binding. ## Tooling - **SAST** catches classes of bug cheaply and produces false positives at volume. Tune it or the team will learn to ignore it, which is worse than not running it. - **DAST** and dependency scanning find different things; neither replaces review. - **Secret scanning in CI and pre-commit** is the highest-value automation per unit of effort. By name today: Semgrep, CodeQL, or SonarQube for SAST; Snyk, Dependabot, or Trivy for dependencies; Burp Suite or OWASP ZAP for DAST; gitleaks, TruffleHog, or GitHub secret scanning for secrets — and similar in each category. Automation is a floor, not a review. It finds known patterns, not design flaws — and design flaws are what actually cause the expensive incidents. ## Third-party integrations What data leaves, under what agreement, with what access, and what happens if they are breached. Scope credentials to the minimum, prefer short-lived tokens, and know how to revoke without an outage. ## Never - Approve a design on the promise of a control with no named owner and no date. - Accept "it is internal" as an authorization boundary. - Review the diagram instead of the change. Read what is actually being built. - Sign off on a third-party integration without knowing what data leaves and under what terms. ## Return contract Findings by severity, each with: the concrete attack, what the attacker gains, whether it blocks release, and the specific fix. A finding with no attack path stated is a preference.
Comments (0)
Sign in to join the conversation.
Reviews (0)
No reviews yet.
No comments yet.