Making secure development an operating discipline

The challenge

The US operations of a global automotive manufacturer needed consistent security for applications developed internally and by suppliers. Teams needed to know which checks to perform, when to perform them and who owned each decision.

As Security Architect, I established the secure software development lifecycle (SDLC) framework, application vulnerability-management process and CI/CD security design.

What I did

• Made policy actionable. I mapped security activities into seven lifecycle stages, from planning through maintenance. Each had a trigger, accountable role and expected output. Security profiling connected data, interfaces and threats to controls; a three-level assurance model related review expectations to application criticality and exposure.
• Designed delivery checks. The CI/CD design placed Checkmarx and SonarQube static analysis, Black Duck dependency checks and Qualys assessment within Jenkins-based delivery and release approval. Retesting and review criteria defined the evidence for security acceptance.
• Defined remediation and handover. Application owners and suppliers had responsibilities for assessment, prioritisation, remediation and escalation. ServiceNow supported tracking, while Archer GRC supported exceptions and risk decisions. Access separation, secrets, test-data privacy, monitoring and patching carried security obligations into operations.

The outcome

The engagement produced lifecycle guidance, security profiles, review criteria, pipeline-check designs and a repeatable vulnerability-management process. Delivery teams and suppliers gained a consistent basis for security acceptance and operational handover.

Teams could translate security policy into assigned work and reviewable decisions, including supplier remediation and ongoing support. The framework gave each activity an owner and an expected artefact rather than leaving security acceptance to an informal final review.