Build an evidence-driven security program
Set ownership and requirements, produce release-specific evidence, manage exceptions and scope external obligations.
- Turn program expectations into accountable release-specific engineering evidence.
- Assess practice maturity, exceptions and supplier claims without overstating scope.
- Separate legal applicability, standards and technical verification.
- Recognize a product owner, release artifact and test record.
- No certification or legal knowledge is assumed; linked dossiers define roles, local policies and scope questions.
Estimated time: about 5.5 hours across 11 steps, including 1 browser lab.
By the end: An assurance dossier containing an operating decision, requirement record, evidence crosswalk, framework choice, improvement plan, exception analysis, scoped supplier/obligation evidence plan and AI system register.
0 of 11 steps complete
Assign states to the supplied findings, identify the unowned service and calculate review capacity.
Keep: A weekly decision record with owners and coverage denominators.
Complete when: Fix ready, verified closed and exception requested remain distinct; the capacity shortfall is visible rather than removed from the denominator.
Open guide : Run an AppSec program: owners, finding states, deadlines and championsUse the versioned ASVS requirement and two-call-site dossier to trace code, negative tests and deployed scope.
Keep: A requirement/evidence/result record another engineer can repeat.
Complete when: An untested or failing call site cannot inherit a pass from another path; one requirement is not a full ASVS-level assessment.
Open guide : ASVS 5.0 verification records: requirement, test and evidence another engineer can repeatRepair the lab’s evidence matching for service, commit, requirement, passed result and all required cases in one run. Compare the complete and split-run fixtures.
Keep: A tested evidence-join rule and final dossier conclusion.
Complete when: Stale, wrong-service, failed and incomplete records leave the relevant requirement missing; a complete scoped record satisfies this model. Deployment identity and the adequacy of assertions require separate evidence.
Open lab : Release evidence lab: Keep stale test evidence out of a release decisionIndex the release evidence you produced, bound to the artifact digest, and map each item to the SSDF, PCI DSS, ISO 27001, SOC 2 and CRA requirements it supports.
Keep: An evidence index with its crosswalk, checked by the guide's script.
Complete when: Each claimed requirement points to a dated record from a real release, and the crosswalk stops where a framework's scope differs.
Open guide : Compliance evidence reuse: one evidence set for SSDF, PCI DSS, ISO 27001, SOC 2 and the CRAMap the supplied preparation, protection, production and response evidence to its actual claim.
Keep: A product-scoped evidence/gap matrix and prioritized actions.
Complete when: Configured review rules and a signature do not prove a review event; final and draft SSDF editions are kept distinct.
Open guide : Apply NIST SSDF (SP 800-218) to one product: practices, evidence and attestation in 2026Use the guide's comparison to decide which question you are answering: outcomes to show evidence for (SSDF), what to improve next (SAMM) or how you compare with peers (BSIMM).
Keep: A one-page note naming the framework for each question your program must answer.
Complete when: Each framework is used for its own job, and no SAMM score is compared with a BSIMM scorecard.
Open guide : BSIMM vs SAMM vs SSDF: what each is for and which to useCalculate coverage and quality from the eligible changes, then choose two improvements under the supplied budget.
Keep: A scoped assessment critique and feasible roadmap.
Complete when: Document counts are not equated with effective review, and local coverage percentages do not award an official maturity level.
Open guide : Run an OWASP SAMM assessment with evidence and a practical roadmapCalculate the supplied loss scenarios, test whether control evidence supports the reduced estimate and apply authority/expiry conditions.
Keep: A reasoned exception decision and cohort metric.
Complete when: An unverified control receives no preventive credit; numeric threshold, accountable approval and expiry each remain necessary.
Open guide : Approve, expire and measure security exceptions without hiding riskCompare hosted-service and privileged-agent uses with report scope, inventory and downloaded digest evidence.
Keep: Two scoped supplier decisions and testable evidence requests.
Complete when: A favorable report for one service does not approve an excluded agent, and an inventory cannot authenticate its updater.
Open guide : Supplier software assurance: check SOC 2 reports, SBOMs and signed updates against your useUse the client/payment dossier to identify reviewers, conditional reporting clocks and missing engineering records.
Keep: A provision/actor/product/evidence plan with dated unresolved questions.
Complete when: Only calculate legal clocks under the stipulated classification; do not infer compliance from a successful test, SBOM or payment outsourcing.
Open guide : Cyber Resilience Act and payment pages: turn product-security obligations into an engineering evidence planFor the three classified AI features, name each duty and the date it applies from, then list the register and engineering changes the high-risk feature still needs.
Keep: An AI system register with roles, risk classes, dated duties and the missing evidence for each.
Complete when: Classification stays a recorded legal decision; every duty has a date and an owner, and an evaluation counts only for the model version actually in production.
Open guide : Turn NIST AI RMF, ISO/IEC 42001 and EU AI Act duties into engineering evidenceWrite an honest release assurance decision
Use the complete synthetic fixture below in a notebook or text file. No live target, paid service or secret is needed. Make your own decision before opening the worked assessment. Then take the implementation option below, a local project in which you repair running code until its tests pass, and keep its test output with your written answers.
A product lead asks for a release sign-off from an incomplete evidence bundle. Produce a scoped assurance record, exception and decision.
Supplied material
Product: tenant invoice API, release r8, artifact digest A. Scope: object reads, export, profile field updates and deployment pipeline. Payment processing and the mobile client are excluded and must not be described as assessed.
Local requirements: R-AUTH owner-or-tenant-finance-admin policy; R-FIELD ordinary users cannot change roles; R-REL deployed artifact must match the verified candidate.
Evidence E1: object-read tests pass on r8/A, including cross-tenant denial; no export tests.
E2: profile-field tests pass on r7/B.
E3: deployment record says tag latest; there is no observed running digest.
E4: reviewer statement says ASVS aligned but has no edition, selected requirement IDs or procedures.
Risk exception X1 proposes allowing untested export for 90 days with owner='security team', no compensating control and no expiry action.
Production policy: cross-tenant disclosure risks block release; a temporary disabled feature may be accepted only with a named product owner, tested disablement, deadline and automatic escalation at expiry.
A remediation branch adds export authorization but has not been built or tested.Work through the case
Build a requirement→implementation→procedure→evidence→status table and distinguish fail, missing evidence and out of scope.
Rewrite X1 into a bounded decision using only the allowed policy, or reject it if the needed conditions are not met.
Choose the precise release claim supportable now and list what changes would alter it.
Specify owner, due date, escalation and evidence retention for every open item.
Decide the fixed cases
These parts of the case have one right answer, taken from the worked assessment. Check them here; the rubric below assesses your written reasoning. The capstone meets the bar when every decision is right and the self-check reaches it.
What does each item establish for release r8 (artifact A)?
Decide the requests.
Evidence to retain
- Scoped assurance matrix with release and artifact identity.
- Rejected or conditional exception record with concrete conditions.
- Release decision that does not claim a whole ASVS level.
- Action list linking missing tests and deployment observations to owners.
Assess your work
Score each criterion with the anchor whose evidence your answer shows: 0, 1 or 2 points. Every anchor describes something a reviewer can point to in your work. Aim for at least 7 of 8, with no unresolved critical failure.
Score your answer against the anchors
Choose the anchor that matches your answer for each criterion.
Recorded checks stay in this browser only, so you can compare attempts. This is a self-assessment, not a certification.
Compare with the worked assessment
E1 supports the tested object-read cases only. Export remains unverified; E2 is stale for r8; E3 cannot establish deployed identity; E4 establishes no verifiable standard claim. Reject X1 as written. A disabled-export release could be considered only after a named accountable owner accepts the bounded residual risk and tests prove export is disabled through all routes, with expiry/escalation and a repair plan. The proposed branch is not evidence for the candidate. Do not release under the supplied policy until required controls or an allowed, verified reduced scope are established. Excluded mobile and payment surfaces remain excluded, not passed.
Save a draft on this device to resume later. Automatic saving begins after you choose Save. Drafts are never sent by this application; use synthetic data.
No draft saved on this device yet.
Implementation option: Build and verify a signed software release
Produce the evidence your release decision asks for: build the release, repair the gate until all 20 tests pass, and record the artifact digest each result applies to.
Keep: Test output tied to the artifact digest, and your assurance matrix updated with the rows this evidence changes and those it does not.
Node.js 22+ · no dependencies · 60–90 min · 20 tests
From source to trusted release
Generate and compare inventory, assess dependency risk, verify artifacts and retain evidence tied to the shipped release.
Your progress, your browser
Progress is stored on this device. Export it to carry it to another browser, or clear it whenever you want. Importing a file adds its completed items to the progress already here; items this site no longer offers are skipped and counted, and nothing else is removed.