Product

One orchestrator, eight security activities.

Each activity is a self-contained security engagement with its own report shape. Run one, or run several together — they execute concurrently against the same target.

security-architecture-review

Security Architecture Review

Controls matrix (presence, placement, layering), a design-principles verdict, operational & regulatory fit, CSA CCM v4 domain conformance, and a Design verdict for milestone gating.

threat-modeling

Threat Modeling

Adversary classes, STRIDE (+ LINDDUN when personal data is in scope), attack chains, every threat dispositioned Mitigated / Gap / Accepted, and an explicit residual risk statement.

sast

SAST — Static Code Analysis

Code-level findings with taint paths, CWE/OWASP mapping, and illustrative fix diffs.

sca-reachability

SCA — Reachability & Upgrade Triage

Dependency inventory, a reachability verdict per risk, and a grouped upgrade plan.

secret-scanning

Secret Scanning — Code, Confluence & Docs

Exposed credentials across source, config, git history, and linked Confluence pages, with a rotation-first remediation list.

prompt-review

Prompt Review

LLM prompt, tool-definition, and agent-behavior security review.

deployment-readiness

Deployment Readiness

Production security and operational readiness review.

responsible-ai-compliance

Responsible AI Compliance

Governance, transparency, fairness, and oversight review — drives the dashboard's Responsible AI risk badges.

Architecture review vs. threat modeling

These two look adjacent but answer different questions and fail differently, so Secfoo keeps them separate rather than merging them into one "threat assessment."

Control-centric · evaluative

Security Architecture Review

Asks is this design sound? Are controls present, correctly placed, and layered? Is least privilege enforced by the topology or merely by policy? Does the design fail safe? It also covers ground with no attacker at all: recoverability, key lifecycle, maintainability, regulatory fit.

Adversary-centric · generative

Threat Modeling

Asks what could go wrong, and who would make it go wrong? Enumerate threats from assets and trust boundaries, then disposition each as mitigated, accepted, or a gap, and state residual risk explicitly.

An architecture review can pass every checklist item and still miss a threat nobody enumerated. A threat model can list fifty threats and still miss that the design has no blast-radius containment. Run both.

Program dashboards

Coverage across every project, not just the last run

Built from what a report can state at review time and the exceptions you record — not a separate persistent findings-lifecycle system with manually-updated statuses. Approximations are labeled honestly, never guessed.

Security Architecture Review

Coverage %CCM v4 conformance heatmapFindings dispositionGate-decision mixRecurring root causes

Threat Modeling

STRIDE × asset-class matrixThreat dispositionRecorded risk acceptancesRecurring archetypesThreats found post-build
Assessments

One case file per review, from Ready to Completed

An Application ID / Security Assessment Request, a review status, and one or more attached runs or uploaded files — like an AI-BOM inventory. The Assessments, Third-Party, and Responsible AI dashboard pages are all built on top of it.

secfoo assessment create \
  --project https://github.com/org/vendor-app \
  --type third-party --app-id APP-042 \
  --sar SAR-2026-0007 --reviewer "Jane Doe"

secfoo run --skill security-architecture-review \
  --agent claude --assessment 1