Secure SDLC in practice for a software company: what to implement first?

Secure SDLC (sometimes we say “DevSecOps”, “secure‑by‑design”) is not a single tool or a “security project”. It is a way of developing and maintaining software in which security is built into the everyday workflow: from requirements and design, through code and the CI/CD pipeline, to handling vulnerabilities after release.

For a software producer (SaaS, on‑prem, vendor, embedded software) one thing is key: to implement Secure SDLC in such a way that it does not kill the delivery pace, but stabilizes it. The best working approach is a staged one, based on standards and “small, measurable steps”.

In this article I will base the order of actions on:

• NIST SSDF (SP 800‑218) as a practical list of “what must be there” areas, divided into preparing the organization, protecting artifacts, developing secure software and responding to vulnerabilities.​
• Microsoft SDL as a proven set of practices (including requirements, threat modeling, secure coding, verification).​
• OWASP ASVS as a reference point for application security requirements (what to test / what to implement).​
• SLSA and SBOM as the foundation for securing the supply chain, which is becoming increasingly important in customer requirements and regulations.
• The European context: the Cyber Resilience Act (CRA) increases the importance of security processes at manufacturers, including in the area of vulnerability handling in the product life cycle.​

Why is the “order of implementation” more important than the list of tools?

Many companies start with SAST/DAST and hope that scanners will “do Secure SDLC”. The effect is often the opposite: the number of alerts grows, morale drops, and real risks (e.g. supply chain, lack of a patching process, lack of requirements) remain.

A safer strategy is to:

• first define the rules of the game and the flow of responsibility,
• then automate quality control (scans, tests),
• and finally raise maturity (broad threat modeling, hard release gates, SLSA by levels).

“Must have” of a producer’s Secure SDLC (7 pillars)

Below are the pillars that really make a difference for vendors:

• Requirements and standard: what “secure” means in your product (e.g. ASVS level 1/2/3).​
• Secure pipeline and artifacts: control of builds, signatures, provenance (SLSA).​
• Dependency management and SBOM: visibility of components and fast reaction to CVEs.
• Secure design (threat modeling): catching classes of errors before code is written.​
• Secure coding + code review: standards, checklists, training (SDL).​
• Verification (SAST/DAST/IAST + security testing): automation and manual tests where needed.
• Vulnerability management & disclosure: process, SLAs for fixes, communication with customers (also important in the EU from a regulatory perspective).

What to implement first? Prioritization “max effect / min friction”

Priority 1: vulnerability process and “who is responsible for what” (PSIRT + VDP)

This is usually the biggest gap in software companies: a vulnerability drops “somewhere into support” and then gets lost in emails. Meanwhile, CRA requires clear procedures for handling vulnerability reports and their remediation throughout the product life cycle.​

What is worth implementing first:

• A public address for reports (e.g. security@yourdomain) and a simple Vulnerability Disclosure Policy (VDP), so it is clear how to report issues and what a researcher can expect.​
• A triage process: determining criticality, impact and affected versions, so that priorities are consistent and not “by gut feeling”.​
• SLAs for response and fix, e.g. Critical – 7 days, High – 30 days (adjusted to your business and risk).
• An ordered process for releasing fixes and publishing security advisories, so that customers know what to do.

Why is this point number 1? Because even the best Secure SDLC will not help if you cannot react quickly and predictably to real vulnerabilities that already affect your product today.

Priority 2: access hygiene and CI/CD pipeline (supply chain “quick wins”)

Supply chain attacks are one of the biggest risks today. SLSA is a practical “checklist” in this area.​

Things to implement right away (without rebuilding the architecture):

• MFA everywhere (repo, CI, cloud), no shared accounts,
• least privilege for CI tokens,
• secrets in a secrets manager, token rotation,
• branch protection (required review, status checks),
• builds only from controlled runners, pinning versions of actions/scripts,
• artifact registry + control over what goes to production.

The effect: lower risk that someone will take over the pipeline and, as part of a supply chain attack, push a malicious build to production.

Priority 3: dependency management + SBOM (visibility = speed of reaction)

SBOM is a formal list of components in your software. NTIA defines the minimum SBOM elements, and CISA maintains materials and updates related to SBOM. If you do not know what you have in your dependencies, you cannot answer a customer’s question: “are you vulnerable to X?”.

What is worth implementing first:

• automatic dependency scanning (SCA) in CI,
• SBOM generation (e.g. CycloneDX or SPDX) as a build artifact,
• a “new CVE” process: identifying affected versions → decision → patch → advisory.

This is a huge boost of trust for B2B customers – you show that you treat security and vulnerability handling as part of the product, not a “side cost”.

Priority 4: “security requirements” as a quality standard (ASVS / SDL)

In practice, Secure SDLC works when dev knows what must be satisfied, and QA/CI can verify it.
OWASP ASVS provides a ready list of requirements for web applications (and services), and Microsoft SDL shows how to weave security practices into the development life cycle.​

How to start lightly:

• choose an ASVS level (often start: Level 1 as a baseline),
• extract from it 10–20 “most painful” requirements (auth, sessions, logging, validation),
• turn it into a Definition of Done checklist for features.​

Priority 5: threat modeling at critical points (not everywhere at once)

Threat modeling is the core of SDL and a great tool for reducing the cost of design errors.​

In a producer’s practice:

• start with 2–3 highest‑risk user journeys: login, password reset, payments, API integrations,
• run short sessions (60–90 minutes): actors, assets, trust boundaries, abuse scenarios,
• the result should be a “list of decisions and mitigations”, not documentation for its own sake.

Implementation roadmap: 30 / 90 / 180 days (realistically)

First 30 days: foundations that immediately reduce risk

• PSIRT/VDP + simple vulnerability process (triage, SLA, advisory).
• MFA, repo and CI protection, secrets hygiene.
• Dependency scanning + basic SBOM as a build artifact.
• Minimum requirement standard (e.g. ASVS Level 1 as “baseline”).

KPIs at the end of 30 days: response time to a vulnerability report, % of projects with dependency scan and SBOM, % of pipelines with MFA/protection.

90 days: automation of quality and security gates “without drama”

• SAST in CI + triage rules (what blocks, what goes to backlog).
• DAST for the most important endpoints / staging environment.
• Threat modeling for the top 2–3 critical paths.
• Secure coding standard (checklist) and required review for security areas (auth, permissions).
• First SLSA elements: build and provenance control where possible.​

KPIs at the end of 90 days: trend of critical vulnerabilities, scan coverage, time to remediate (MTTR) for high/critical.

180 days: producer maturity (compliance‑ready + process scalability)

• SLSA by levels (raising requirements for builds and artifacts).​
• SBOM + update process + integration with vulnerability intel (fast responses to customers).
• Program for reducing “classes of vulnerabilities” (e.g. injection, SSRF, auth bypass) – in line with the Secure by Design approach promoted by CISA for vendors.​
• Regular penetration tests / red teaming for critical modules.
• “Security champions” in product teams (to scale practices).

How to implement this so that dev does not hate Secure SDLC?

Rule 1: not everything “blocks the release”

Define a policy:

• what blocks (e.g. critical dependency vulnerabilities in an internet‑facing component),
• what requires a plan (high),
• what can be backlog (medium/low).

Without this, Secure SDLC turns into an “alert factory”.​

Rule 2: triage is more important than the number of tools

NIST SSDF directly treats this as an organizational practice: prepare the organization, protect software, produce well‑secured software, respond to vulnerabilities. You can drown in tools, but good triage and sensible SLAs make the real difference – this is the “mechanics” that actually delivers a functioning vulnerability response process.​

Rule 3: security requirements must be “testable”

ASVS helps because its requirements can be directly mapped to specific tests and security controls, so they do not remain “on paper”, but translate into practice.​

Minimal set of “policy / documents” that really make sense

• Secure SDLC Policy (1–2 pages): scope, responsibilities, gates.
• VDP / vulnerability disclosure policy + contact.
• Dependency standard: who approves new libraries, how to react to CVEs.
• Secure coding checklist (short, practical).
• Release security checklist (SBOM, scans, signatures, rollback plan).

Most common producer mistakes (and antidotes)

• Starting from DAST in production → start from pipeline, SBOM and vulnerability process (less chaos).
• No vulnerability owner → appoint PSIRT (even 2 people) and set SLAs.
• “We turn on SAST and see” → without triage and blocking rules you will stop development.
• SBOM as a PDF once a quarter → SBOM must be a build artifact (repeatable and up‑to‑date).

Best order of implementation

• Vulnerability handling (PSIRT + VDP + SLA),
• Access hygiene + securing CI/CD,
• SCA + SBOM + CVE response process,
• Requirement standard (ASVS as baseline) + DoD,
• Threat modeling for critical paths (SDL),
• SAST/DAST with triage rules and sensible gates,
• SLSA by levels + hardening the supply chain.

‍