TL;DR
Most software development security requirements are written as intentions, which means nobody can pass or fail them. "Dependencies must be secure" reads well and survives review, right up to the moment an auditor asks to see the file. This software security requirements checklist gives you 12 lines written the other way round.
- A requirement is only verifiable when three things exist. A named artifact, a moment it gets checked, and a defined behaviour when the check fails. Most software security requirements fail on the first.
- Each of the 12 lines produces evidence. A provenance attestation, an SBOM tied to a released version, a revocation timestamp, a gate decision with an owner. Not a scanner report.
- They split into three groups. What enters your software, what builds it, and what proves the state of it.
- Verifying them is an SSCS and ASPM problem, not a scanner problem. Six tools produce six dashboards, and an auditor wants one answer. The evidence has to come from one place or it does not come at all.
Why do most software development security requirements fail the moment someone audits them?
Open almost any security requirements document, and you will find sentences like “third-party components must be free of known vulnerabilities” and “the build pipeline must be secured”. They read well. They survive review. And then an auditor, a customer security questionnaire, or a NIS2 or DORA assessor asks a simple question: show me.
At that point the requirement collapses, because nobody wrote down what “free of known vulnerabilities” means at which point in the lifecycle, who decides, and what file you hand over. The team scrambles, exports a scanner report, and hopes the volume of findings reads as diligence.
The gap is not effort. Teams running four or five tools are doing plenty of work. The gap is that software security requirements were written to describe a desired state instead of a checkable event. A desired state has no evidence attached to it. An event does. Everything that makes software development security auditable comes from that distinction.
What makes a software security requirement verifiable?
Three properties, and a requirement needs all three:
- A named artifact. An attestation, an SBOM, a signed record, a gate decision. Something that exists as a file or a log entry and can be produced on request.
- A moment. Pull request, build, release, or continuously. “At some point in the SDLC” is not a moment.
- A defined failure behaviour. What happens when the check fails: block, warn, quarantine, or route to a named owner with a documented exception path.
Run your current requirements through those three properties. Most of them will fail on the first, which is why teams end up negotiating with auditors instead of answering them.
The 12 lines below are written so that each one passes all three. They are deliberately boring. Verifiable requirements usually are.
The software developement security requirements checklist: 12 lines that can actually be verified
Each line names the artifact that proves it, the question that tests it, and where the evidence comes from.
Group one: what enters your software
| Requirement | Verify by | Evidence |
|---|---|---|
| 01Every dependency is screened for malicious behaviour without waiting for a published signature | Requesting the screening verdict for any package added in the last 30 days | Malware Early Warning detects malicious packages across code, pipelines, IaC and registries before a signature or advisory exists, using evidence detection followed by AI validation |
| 02Every release has an SBOM, retrievable by version, generated by the build rather than assembled by hand | Naming a released version and asking for its SBOM inside five minutes | SBOM generation per build, with vulnerability disclosure reporting attached |
| 03A vulnerability only blocks a release when it is reachable in your code | Taking three blocked findings and asking which function path makes them exploitable | Reachability at function level, exploitability and EPSS inside the prioritization funnel |
| 04Known-vulnerable components carry an owner and a decision, not just a ticket | Picking any open critical finding and asking who accepted the risk, and until when | Ownership and status tracked against the asset, not against a scan run |
| 05AI and machine learning dependencies are treated as ordinary supply chain, because they are | Asking which CVEs affect the ML libraries in production today | Composition analysis covering the AI stack in the same platform as the AI assets that use it |
Group two: what builds your software
| Requirement | Verify by | Evidence |
|---|---|---|
| 06Every build produces a provenance attestation that can be verified independently | Pulling the attestation for the most recent production artifact and checking it against the source commit | SLSA provenance and custom in-toto attestations with keyless signatures, stored in any registry, with tampered artifacts blocked before delivery |
| 07Pipeline configuration is scanned as code, on the same cadence as application code | Asking when the last GitHub Actions or Jenkins configuration change was security reviewed, and by what | CI/CD security covering pipeline misconfiguration, poisoned workflows and supply chain risk, with SSCS compliance built in |
| 08Every secret found anywhere in the lifecycle is revoked, not merely reported | Asking for the last five detected secrets and their revocation timestamps | Detection across code, configs, containers and pipelines with over 100 secret types, plus automatic revocation playbooks per credential type |
| 09Anomalous activity in the pipeline raises an alert before it becomes an incident | Asking what a compromised runner or an unusual commit pattern would trigger, and who receives it | Anomaly detection on activity that precedes an attack |
Group three: what proves the state of your software
| Requirement | Verify by | Evidence |
|---|---|---|
| 10Infrastructure as code is gated before merge, not corrected after deployment | Asking whether an insecure Terraform change can reach main, and what stops it | IaC scanning with guardrails at the pull request |
| 11Findings from every tool, yours and third-party, share one severity model | Asking whether a critical from one scanner and a critical from another mean the same thing to your team | The ASPM layer ingests findings from the SAST, SCA, DAST and IaC tools you already run, whoever built them, and applies the same prioritization, triage, explanation and remediation as it does to native findings |
| 12Every AI asset in the codebase is inventoried and exportable | Asking which models, agents and MCP servers are running in your applications, and requesting the file | Continuous discovery of models, frameworks, datasets, inference endpoints, agents, MCP servers, skills, prompts and AI coding tools, with a CycloneDX ML-BOM generated on every scan |
Who owns each line of the checklist?
A requirements document with no owner column is a wish list. Assign each line before you publish it:
The second column is the one that fails in practice. Continuous verification only works when the evidence collects itself.
How do you verify a software developement security requirements checklist without adding another console?
This is where most programmes stall. The 12 requirements above touch dependencies, pipelines, build artifacts, secrets, infrastructure code, and AI assets. Verify them with six separate tools, and you have created a seventh job: reconciling six dashboards into one answer for an auditor who wants a single number.
Two capabilities make this tractable.
- Software supply chain security (SSCS) covers the requirements that live between the commit and the artifact. Dependencies, pipelines, build integrity, secrets and anomalous activity are one attack surface, and they are also where the hardest-to-fake evidence comes from: a signed attestation is worth more to an assessor than a scanner report, because it cannot be regenerated after the fact.
- ASPM is the layer that turns findings into a posture you can report. It matters here for a specific reason: it ingests what your existing scanners already produce. You do not have to replace the tooling you already paid for to satisfy this checklist. Its output becomes an input, and the same prioritization, AI triage, explanation, and remediation applies to those findings and to native ones. A software development security programme built on a platform that only understands its own scanners will fail every time the estate is mixed, and every estate is mixed.
What changes when an agent writes the code?
Everything above assumed a human wrote the change and another human reviewed it. That assumption is expiring, and it is reshaping what software development security has to cover.
When a coding agent produces a thousand files in a week, code review stops being a control and becomes a queue. Three of the 12 lines carry most of the weight in that world: malicious dependency screening (because agents pull packages fast, and hallucinated package names are now a registered attack vector), pull request analysis ranked by exploitability rather than raw severity, and AI asset inventory.
There is also a fourth requirement worth adding to any software security requirements checklist written in 2026: the configuration files that instruct your AI tooling are reviewed as security artifacts. Skill files, rules files and MCP server configurations are committed as plain text and reviewed as though they were documentation, and they define what an assistant is instructed to do and what it is allowed to reach.
How do you get from checklist to evidence?
Do not start by rewriting the whole document. Take the three lines your next audit, customer questionnaire, or board review will actually test, usually SBOM on demand, secret revocation, and build provenance. Prove those three end to end, with the artifact in hand. Then extend.
Software development security requirements checklist is not a document exercise. It is the difference between a security programme that can answer questions and one that can only describe itself. Twelve verifiable lines beat forty aspirational ones, because twelve of them survive contact with someone who asks to see the file.
If your software security requirements cannot produce an artifact on demand, you do not have requirements. You have intentions with a version number.
See what your estate already proves. Connect a repository, and Xygeni returns your dependencies, pipelines, secrets, build integrity status, and AI inventory in a single posture view, with the evidence attached to each finding. Start free or book a demo.
FAQ
How many software security requirements should a checklist have?
Fewer than you think. The useful number is the number you can verify on demand, which for most teams is between 10 and 20. A checklist of 60 requirements where 45 have no evidence attached is weaker than a checklist of 12 where every line produces an artifact. Start with the lines your next audit will test and extend from there.
What is the difference between software development security and a compliance framework?
A framework such as NIS2, DORA, or the Cyber Resilience Act tells you what outcomes are expected. Software development security is how those outcomes become checks your engineering team can pass or fail on a given pull request or build. Frameworks are written for assessors, requirements are written for developers, and most of the pain in a compliance programme comes from nobody doing that translation.
Can I verify a software security requirements checklist with the scanners I already have?
Partly. Scanners produce findings, and several of these requirements need artifacts instead: a provenance attestation, an SBOM tied to a released version, a revocation record, a gate decision with an owner. That is why the checklist sits on SSCS and ASPM rather than on a scanner. The practical route is to keep your existing scanners and put a layer above them that ingests their findings and applies one prioritization model to all of them.
Which requirement do teams most often get wrong?
Secrets. Almost every checklist says secrets must not be committed, and almost none says a detected secret must be revoked within a defined window. Detection without revocation leaves a live credential in a repository’s history, and history is public the moment the repository is. Rewrite that line as a revocation requirement with a timestamp and it becomes verifiable.
