Building a secure development lifecycle that holds up as evidence

The practices a lifecycle has to cover

• Security requirements definition, derived from risk assessment rather than from a generic checklist.
• Secure design, including defence in depth, least privilege, attack-surface reduction and documented design review.
• Secure implementation practices: coding standards, review expectations, dependency management, secret handling and reproducible builds.
• Verification and validation: static analysis, dependency and licence scanning, security testing, and where risk warrants it, penetration testing.
• Defect and vulnerability management, covering both internally found defects and externally reported vulnerabilities.
• Patch and update management, including the mechanism by which updates reach deployed products.
• Product end-of-life and end-of-support handling, communicated to users.

IEC 62443-4-1 organises this into eight practices with defined requirements, which makes it a useful backbone even for teams outside industrial automation, because it is specific about what evidence each practice should leave behind.

Introducing a lifecycle without stopping delivery

• Start from the pipeline, not the policy. Dependency scanning, SBOM generation and static analysis added to CI produce records from day one and require no process negotiation.
• Define the smallest useful set of security requirements for the next release, tied to the threat model, rather than a full requirement catalogue nobody reads.
• Introduce one gate at a time: design review before implementation, then verification evidence before release.
• Record decisions where the work happens — issue tracker, review comments, pipeline artefacts — and generate documentation from those records rather than maintaining a parallel document set.
• Assign named owners for vulnerability intake, release approval and the support-period commitment. Unowned obligations are the ones that fail during audit.

What auditors and integrators actually check

Reviewers look for consistency between the documented process and the artefacts a real project produced: does the release you are claiming conformity for have the review records, test evidence and SBOM the process says it should have? A modest process that is demonstrably followed passes; an ambitious process with no matching records is a finding. Integrators performing supplier assessments ask the same question in commercial form, usually by requesting evidence from a specific recent release.

Relationship to functional safety processes

Organisations that already run an ISO 26262 or IEC 61508 development lifecycle have most of the structural machinery in place: requirement traceability, review discipline, verification planning, configuration management and change control. The efficient path is to extend those mechanisms to cover security requirements and security verification, keeping one traceability structure, rather than building a second parallel lifecycle that has to be kept consistent by hand.

Frequently asked questions