Secure development: requirements to evidence

“Make the app secure” is difficult to implement or verify. “A removed project member cannot export its documents” gives developers and reviewers something concrete to build and check.

Security requirement: A defined security behavior or property that a system must satisfy and that reviewers can evaluate.

Define the behavior, including denial

Describe who may perform an action, on which resource, and under which conditions. Include misuse and error cases. A requirement should identify what the system does when a check fails, not just when everything succeeds.

Make the requirement visible in design and review. For sensitive workflows, consider default settings, recovery behavior, data retention, and how changes affect existing sessions.

Use complementary checks

Code review can identify design mistakes and missing context. Automated tests can repeatedly verify known behavior. Static analysis and dependency checks can flag certain patterns and known issues. None proves the absence of all vulnerabilities.

Use synthetic users and records to verify both allowed and denied operations. A test that only checks an administrator’s success does not demonstrate that outsiders are blocked. Keep test data free of real secrets and personal records.

Ship with a way to learn and repair

Before release, know what was reviewed, what failed, and what limitations remain. A narrow justified exception should have an owner and a review date. Protect the release process and separate approval from broad production authority where practical.

After release, maintain dependencies, monitor relevant failures, provide a reporting channel, and plan fixes and rollback. Repeated defects should improve the shared design or development practice, not merely produce isolated patches.

Follow one requirement across the trust boundary

Imagine a fictional community archive adding scheduled document exports. The browser submits a request, the application checks policy, a worker prepares a file, and storage later delivers it. Each handoff changes which component has the information needed to enforce the rule. Reviewing only the browser screen leaves the worker and delivery policy unexplained.

The product owner specifies: “A requester must be a current project editor when the export is delivered. A denied delivery returns no document contents.” Engineering identifies the enforcement point and the source of current membership. Reviewers then ask whether the proposed evidence establishes that exact behavior for the version being released.

The last column makes evidence more useful, not less valuable. It prevents a narrow observation from becoming a universal claim. Record the requirement identifier, the reviewed change, the fixture or scenario, the observed result, and any remaining uncertainty. Someone reviewing next month should understand what was actually established.

Review changes to assumptions, not only changed lines

A dependency update may alter defaults or error behavior even if the application changes little. A new cache can change how quickly revoked permissions take effect. A new background task may perform an existing action under a different identity. Ask which earlier security assumption each change relies on and whether it still holds.

Automated checks are strongest when their scope is clear. A dependency report may identify known affected versions but still require review of the actual component and its use. A targeted permission check can verify a synthetic relationship while missing a new export path. Review, tests, and operational observations support different claims; collecting more green badges is not a substitute for connecting them to requirements.

PredictAll checks passed before a late change added logging inside the export error handler. May the team reuse the earlier evidence unchanged for the final release?

Not for claims affected by the new handler. Review whether it records sensitive values, changes error behavior, or affects delivery, then obtain focused evidence for those consequences. Unrelated evidence can remain useful. Restarting every review from zero is unnecessary, but treating an unreviewed change as covered would overstate the result.

Make acceptance and repair explicit

A release decision should distinguish a failed requirement from missing evidence and from an accepted limitation. A known confidentiality failure is not resolved merely by adding an owner to an exception. The accountable decision-maker needs the consequence, exposure, compensating control if any, and a reason the residual risk is acceptable.

Operational readiness also needs a person who can respond, a way to detect relevant failure, and a recovery plan that fits the changed data. Restoring an older application cannot undo information already disclosed. Use lessons from recurring defects to improve shared requirements and review patterns, while keeping each new decision tied to its own evidence.

EXPLORE THE CONCEPT

Which evidence supports release?

A team is shipping a fictional document-export feature.

An explicit owner/outsider permission test

This verifies a meaningful boundary with known data. Review other paths that expose the same documents too.

A scanner reported zero findings

This is one result within the scanner’s coverage. It does not establish that the business rules are correct.

An exception has no owner

Nobody is accountable for resolving or reviewing the limitation. Assign ownership and an expiry or review date.

A simplified learning model. It connects to no systems and uses no real data.

Turn the idea into a decision

Keep a short chain from requirement to implementation to evidence. That chain makes review and later maintenance easier.