Security Evidence Has a Delivery Schedule

On September 24, NIST added three practical resources to its DevSecOps project: a mapping to the Secure Software Development Framework, a CI/CD and container-deployment example, and scenarios showing activities across the software lifecycle. The live reference is open for public comment through November 9.

The project connects security work to development, builds, packaging, distribution, and deployment. For a technology leader deciding whether a change can ship, that raises a concrete question: can the evidence be traced to the exact version being released?

The release record below is an editorial recommendation for a smaller team, rather than a NIST-mandated form. Its purpose is to connect existing evidence to the decision that uses it.

A release is a chain of handoffs

Most software changes pass through more people than the final approval suggests. A developer changes code. A build system assembles it. Tests produce results. A security tool raises findings with varying severity and confidence. An operations person checks a deployment condition. A product or business owner decides whether a delay is acceptable.

Each handoff can lose context. A finding without the affected version is hard to judge. A passed test without its scope can be falsely reassuring. An exception without an owner or an expiration date can quietly become permanent. A deployment note without a rollback condition is not much help at 4:45 on a Friday.

The answer is not to make every small change endure a ceremonial review board. It is to decide, before the release rush, what information must accompany a change and who is allowed to make the call when that information is incomplete.

Build a release record people can actually use

For a modest internal application or a vendor-managed customization, the record may be a ticket, pull request, or short release note. The format matters less than the questions it answers:

• What is being released? Name the version, environment, and material components or configuration changes.
• What evidence was produced? Link the relevant test, review, dependency, or deployment results, and state their scope.
• What remains open? Describe material findings, known limitations, and the conditions under which an exception is acceptable.
• Who accepted the remaining risk? Record the person or role with authority to decide, plus any expiry or follow-up date.
• What happens if the change misbehaves? Identify the monitoring signal, rollback or recovery path, and the person who will act.

These are not five new pieces of paperwork if the team already has useful evidence. They are a way to connect information that otherwise lives in separate tools, inboxes, and memories. The release record should point to the original evidence, not become a handwritten copy that immediately goes stale.

As an illustrative record, a release ticket might link version 2.4 to its test run and identify one unresolved dependency finding. The acceptance entry would name the authorized reviewer, the compensating condition, and the date for reconsideration. A successful run for version 2.3 would not establish what was checked in 2.4. Nor would a signed exception prove that its stated condition actually holds.

Exceptions need an arrival time and a departure time

Exceptions are where a delivery schedule becomes visible. A team may have a legitimate reason to ship with a known limitation: a compensating control exists, a fix is being tested, or the affected path is not enabled. What matters is that the explanation reaches the accountable decision-maker before the change goes live.

It also needs an ending. An exception should identify the condition it covers, its owner, and the event or date that forces a new decision. Otherwise, the organization has not accepted a bounded risk; it has created an undocumented feature of its operating model.

This is distinct from declaring a security problem “fixed” after the fact. Post-incident remediation asks whether a patch, cleanup, and investigation are complete. A release record asks a different, earlier question: based on what we know today, can this exact change proceed under these conditions?

Make the decision legible

Small organizations often have an advantage here. The people who understand the customer impact, the technical change, and the operational constraint may be close enough to have a useful conversation. But that only helps if the relevant evidence reaches them in time.

Before the next release, choose one change and trace the information it needs from code or configuration through deployment. See whether a person outside the immediate technical team could identify the build, the checks, the open condition, the decision-maker, and the recovery plan. If not, the security work may be happening. Its evidence just has not arrived where the decision is made.