Secure implementation and code review procedure

Secure implementation and code review procedure

DE-01 — Work authorisation and preparation

The implementer identifies the approved requirement, defect, vulnerability treatment or change record authorising the work. The record states the intended result, scope, acceptance criteria and applicable constraints. The implementer checks the current baseline and relevant architecture decisions before making changes. Ambiguity that affects behaviour, authority or stakeholder intent is recorded for the responsible decision-maker.

Exploratory work can be authorised with a stated purpose and boundary. Its outputs remain identified as exploratory until incorporated through the adopted change process. The implementer does not infer approval to change unrelated behaviour from permission to edit a component. Work records preserve the reason for a change so that a reviewer can compare the implementation with the intended result.

DE-02 — Secure implementation requirements

Code handles untrusted inputs at the boundary where they enter the system. Validation checks the permitted structure, size, range and meaning for the operation, with output encoding appropriate to the destination. Database and command interfaces use mechanisms that preserve the distinction between data and executable instructions. Authentication and authorisation checks apply to the requested action and resource, including server-side operations where a user interface has already performed a check.

Implementation protects sensitive information in storage, transit, error responses and logs according to the selected requirements. Error handling records useful diagnostic information without exposing secrets or creating unintended authority. Resource limits, cancellation, retries and concurrency are considered where they can affect availability, integrity or the completion of security-relevant state changes.

Security mechanisms use supported, reviewed platform capabilities where selected by the architecture. Changes to cryptography, identity, access enforcement, input processing or update integrity receive review appropriate to their consequences. The implementer records relevant limitations and dependencies. Comments and documentation explain assumptions needed to maintain the security property, rather than simply asserting that the code is secure.

DE-03 — Dependencies and build inputs

New or changed dependencies enter the supply-chain process. The implementer records component identity, version, source, purpose and applicable licence or usage conditions. Dependency selection considers maintenance, known vulnerabilities, integrity information and compatibility with the system’s requirements. Transitive dependencies are included in the release inventory through the available tooling and review process.

Build inputs and configuration are controlled sufficiently to identify how a delivered artefact was produced. The engineering owner records lockfiles or equivalent version resolution, build definitions, tool versions and environmental assumptions where they affect the result. Reproducibility requirements are stated where adopted; a repeatable build claim is supported by evidence rather than inferred from using an automated pipeline.

DE-04 — Code review

The reviewer receives the intended change, relevant requirements, implementation diff, tests and known limitations. Review checks whether the change performs the authorised behaviour and preserves required existing behaviour. The reviewer examines boundary handling, authority checks, information exposure, failure paths, dependency changes and maintainability in the context of the surrounding system.

Review findings identify the affected location, reason, consequence and required action or decision. The implementer records the response and links resulting changes. Approval identifies the reviewed revision and scope. Material changes after review are returned for the review required by the adopted process. Automated analysis can contribute findings, but its output is interpreted and its coverage recorded.

DE-05 — Developer verification

The implementer performs the checks required by the work and verification plan, including relevant functional, error-path and security tests. Tests have an observable expected result and identify the property they examine. A test that reproduces the implementation’s logic without an independent expected outcome is assessed for the confidence it can provide. Existing tests affected by the change are reviewed for continued validity.

Results identify the source revision, environment, command or method, actual outcome and retained evidence. Failed or unperformed checks remain explicit. A running earlier release is not proof that current source compiles or passes its tests. A claim about a build is connected to the exact source and build evidence on which it relies.

DE-06 — AI and generated contributions

Generated code, tests, configuration and documentation enter the same authorisation, review and verification process as other contributions. The work record identifies the use of an AI tool where required by the adopted AI policy and records relevant provenance and limitations. The person responsible for the contribution checks that generated changes match the intended scope and do not introduce unexplained requirements or permissions.

Tool-supplied claims about successful execution, security or compliance are checked against direct evidence appropriate to the claim. Suggested dependencies and APIs are verified in the actual environment. The reviewer considers generated tests and generated implementation together so that a shared incorrect assumption is not mistaken for independent confirmation.

DE-07 — Completion and handover

The implementer updates required documentation, configuration and dependency records. The completed work links to review decisions, verification results and unresolved matters. Integration follows the change and release procedures, preserving the relationship between the approved revision and the built artefact. The owner identifies any operational action, migration, monitoring change or user communication needed when the work is deployed.

Implementation record: [DE ID; authorising requirement/change; scope]
Source and contribution: [Revision; contributors; generated material]
Security considerations: [Boundaries; permissions; data; dependencies]
Review: [Reviewer; revision; findings; resolution; decision]
Verification: [Tests; environment; results; evidence; unperformed checks]
Handover: [Documentation; configuration; migration; open actions]