Secure Software Lifecycle and DevSecOps
Integrate security into the life cycle from the product objectives to the controlled decommissioning.
A Secure Software Lifecycle (SSLC, sometimes also called SSDLC) combines security work with planning, development, build, deployment, operation and decommissioning. The abbreviations are used differently in organisations; What is meant is a security model over the life cycle. DevSecOps is its operational implementation. NIST SSDF v1.1 provides a risk-based framework for this, not a one-size-fits-all checklist or guarantee of compliance.
Background
Software is rarely created in a single team or tool. Proprietary code, open source dependencies, build systems, cloud services and operating platforms form a supply chain. If security decisions are only checked before release, waiting times, unclear exceptions and risks that are difficult to understand arise. Likewise, weak points in the field often remain disconnected from the development process without clear feedback.
An SSLC therefore creates binding transitions: What needs to be clarified before an architectural decision is made? What evidence belongs to a release? Who assesses risks and exceptions? How do insights from vulnerabilities, incidents and changes flow back into the product and platform?
Technical context
NIST organizes its Secure Software Development Framework (SSDF) into four practice groups: preparing the organisation, protecting software from manipulation and unauthorized access, producing well-secured software, and responding to vulnerabilities. The practices should be integrated into existing development models, adapted to risk and continuously improved.
An SSLC is therefore not a specific CI/CD product. Git repositories, pipelines, artifact repositories, cloud or container platforms are possible implementation variants. It is crucial that security requirements, changes, approvals and documents remain consistently controllable across these variants.
What companies need to clarify specifically
- Which products, components, repositories, build environments and suppliers belong in the scope?
- Which security requirements, threats and architectural decisions need to be documented early?
- Who can modify or share code, build definitions, secrets, artifacts, and production environments?
- Which automated and manual controls match the risk and how are exceptions decided?
- How are vulnerabilities, security events and end-of-life requirements traced back into planning and operations?
Typical anti-patterns
- Secrets are stored in repositories or unprotected in pipeline variables.
- Runner and build environments are not sufficiently separated or hardened.
- Artifacts can be replaced after release (mutable artifacts).
- Exceptions remain without owner, expiration date and re-evaluation.
- The origin of a build cannot be traced down to the source version, build definition and dependencies.
- There is no end-of-life process for components and products.
From requirements to implementation
Planning
Risk: Security requirements are lacking
Organisational measure: Security requirements, ownership and risk decisions
Technical implementation: Backlog and architecture templates
Possible evidence: Requirements and decision protocols
Development
Risk: Unsafe changes or secrets
Organisational measure: Review rules, safe development environment, training
Technical implementation: Branch protection, secret scanning, code review
Possible evidence: Review and Scan Results
Build and deployment
Risk: Manipulated or unverified artifacts
Organisational measure: Release criteria, separation of roles and environments
Technical implementation: Secured pipelines, artifact storage, signing on demand
Possible evidence: Build provenance, release approval
Operations
Risk: Vulnerabilities remain untreated
Organisational measure: Monitoring, vulnerability and incident process
Technical implementation: Inventory, scans, alerting, patch workflow
Possible evidence: Tickets, SLAs, operational reports
Decommissioning
Risk: Outhed components remain accessible
Organisational measure: End-of-life plan, data and key handover
Technical implementation: Shutdown, archiving or deletion as specified
Possible evidence: Decommissioning record
Working with ADIUMENTO
Advice or implementation of individual modules requires a confirmed portfolio and a specific order. This specialist page does not describe a stand-alone DevSecOps offering, nor does it describe any certification or promise of regulatory conformity.
Typical deliverables
- SSLC target image with responsibilities and phase transitions;
- prioritised DevSecOps roadmap for processes, platform and teams;
- security requirement, review and exception procedures;
- Evidence structure for builds, approvals, components and operations;
- Feedback for vulnerabilities, incidents and decommissioning.
Limitations and dependencies
Automation does not replace architectural decisions or qualified reviews in high-risk areas. Effectiveness depends on maintained inventories, secured development environments, the quality of dependency data and functioning vulnerability management. SBOM formats, signing procedures and concrete platform configurations are independent specializations.
Further official sources
- NIST SP 800-218 Secure Software Development Framework – NIST
- European Commission: Cyber Resilience Act – European Commission
- Microsoft Secure Future Initiative / SDL overview – Microsoft
Orientation
Frequently asked questions
Is DevSecOps only CI/CD security?
No. CI/CD controls are an important building block, but DevSecOps starts with roles, requirements and architecture and ends with operations, vulnerability remediation and decommissioning. A pipeline alone does not prove a secure life cycle.
How do teams start without a complete reorganization?
With a clearly defined product or delivery route: identify responsibilities and current control points, prioritise the biggest risks and integrate a few verifiable improvements into the existing process. Processes and automation can then be scaled step by step.
Where are SBOM, signing and operations discussed in more depth?
SBOM and dependency management covers transparency and control of dependencies; Code signing and Microsoft Artifact Signing covers integrity and provenance of artifacts. For detection and reaction during operation see Defender, app control, monitoring and incident response.
Next sensible step
Analyse a specific software delivery path: planning, code, build, release and operation. If the project fits the confirmed portfolio, you can IT Security & Compliance and Services give the right entry.