30/60/90 Secure SDLC Practices Playbook for Engineering Teams

Secure SDLC playbook title card

Secure software development lifecycle practices mean building security checks and decisions into every phase of building software, not bolting them on before release. The highest-impact starting points are threat modeling during design, automated SAST and SCA scans inside your CI pipeline, and locked-down secrets and pipeline permissions. Teams that adopt these three first typically see fewer vulnerabilities reach production, faster remediation when issues appear, and lower overall cost per fix.

TL;DR:

Implement threat modeling early in design and automate static analysis and secret scanning within the CI pipeline to reduce vulnerabilities reaching production.

Classify data from the start and incorporate security activities into each SDLC phase, including architecture review, secure coding, testing, and deployment.

Enforce policies as code, protect build processes, and tune automation to surface only high-priority findings to prevent alert fatigue.

Continuously scan dependencies with SBOMs and SCA tools, set explicit allow and deny lists, and patch high-severity issues within defined timeframes.

Conduct manual penetration tests at the pre-release stage to identify business logic flaws that automated tools often miss.

Why convert your SDLC to a secure SDLC
Secure practices for every SDLC phase: requirements to operations
Shift-left automation: building DevSecOps into CI/CD
Secure coding, peer review, and the developer workflow
Supply-chain hygiene: SBOMs, SCA, and dependency risk
Choosing the right testing mix: SAST, DAST, IAST, and manual pentests
Governance, metrics, and the roles that keep it running
Triaging and remediating vulnerabilities without stalling delivery
A practical 30/60/90-day rollout plan
Earthshaker Security: pairing automation with manual verification
Building incident response into the SDLC
Privacy and compliance across the SDLC phases
What teams get wrong about shifting left
How Earthshaker Security can help you close the gap
FAQ
Sources

Why convert your SDLC to a secure SDLC

The case for secure SDLC practices is mostly about timing. Fixing a flaw in design or during coding costs far less than fixing the same flaw after release, when it has already shipped, been deployed, and possibly been exploited. Industry analyses describe this gap as orders of magnitude, since a late fix means a hotfix, a rollback, incident response, and sometimes breach disclosure, not just a code change.

There's a compliance angle too. Contracts increasingly require evidence of a secure development process, and regulators in several sectors expect documented security controls across the development lifecycle. Teams that can point to a consistent, auditable process have an easier time with procurement reviews and security questionnaires than teams improvising controls after a client asks.

The two most cited frameworks for structuring this work are the Secure Software Development Framework from NIST and the Microsoft Security Development Lifecycle. NIST's SSDF identifies a core set of high-level practices meant to integrate into whatever SDLC model a team already uses, rather than replacing it. Microsoft's SDL lists ten foundational practices, including governance, threat modeling, supply-chain controls, and security testing, mapped to specific stages of development.

A secure SDLC does not have to slow delivery down. GitLab's guidance on shift-left security notes that early detection through tuned automation reduces the compounding costs of late fixes, which is what actually protects velocity over a full release cycle. The guardrails that feel slow in week one usually save weeks of firefighting by week twelve.

Done well, secure SDLC work becomes invisible most of the time: a linter catches a bad pattern before a pull request opens, a dependency scanner flags a vulnerable package before merge, and a threat model catches a design flaw before a single line of code exists.

Why convert your SDLC to a secure SDLC — overview diagram

Secure practices for every SDLC phase: requirements to operations

Security work looks different at each stage, and trying to apply the same checklist everywhere is why many programs stall. Here's what belongs in each phase.

Requirements. Define security acceptance criteria alongside functional ones: what data will the system touch, how sensitive is it, and what compliance regime applies. Classify data early (public, internal, confidential, regulated) because that classification drives encryption, retention, and access decisions downstream. Decide now whether the project needs a software bill of materials, since retrofitting SBOM generation onto a finished system is harder than building it in from day one.

Design. This is where architecture review and threat modeling earn their keep. OWASP's developer guidance recommends embedding security activities into Requirements, Design, Implementation, and Verification rather than treating security as a separate gate. A STRIDE or MITRE ATT&CK-informed threat model, run against the proposed architecture, surfaces design flaws (missing authentication boundaries, overly broad trust zones) while they're still cheap to redraw on a whiteboard.

Implementation. Secure coding standards, enforced through linters and static analysis, catch the common mistakes before a human reviewer ever sees the code. Secret scanning on every commit prevents credentials from landing in version history. Dependency policies decide which libraries are acceptable and which versions are stale enough to block a merge.

Testing. This is where SAST, DAST, and IAST each find different problems, and the placement matters: static analysis in the IDE and pull request, dynamic analysis against a running staging environment, and periodic manual penetration testing for the business logic flaws that automated tools consistently miss. Gate merges on critical findings, not on every finding, or developers will learn to ignore the tool.

Release and operations. Progressive exposure (canary releases, feature flags, staged rollouts) limits the blast radius of anything that slipped through testing. Runtime monitoring catches what static and dynamic testing couldn't predict, and a short feedback loop that routes production incidents back into the backlog is what turns one bad release into a permanent improvement instead of a recurring one.

Requirements: security acceptance criteria, data classification, SBOM scope.
Design: architecture review, STRIDE threat modeling, secure-by-design defaults.
Implementation: secure coding standards, secret scanning, dependency allowlists.
Testing: layered SAST/DAST/IAST, merge gating on critical severity only.
Release and operations: progressive exposure, runtime monitoring, incident feedback loop.

Pro Tip: Run your first threat model on the system you already shipped, not just new projects: it almost always finds something worth fixing immediately.

Shift-left automation: building DevSecOps into CI/CD

Shift-left security only works if it lives inside the tools developers already use, not in a separate portal nobody opens. Policy-as-code tools like Open Policy Agent or HashiCorp Sentinel let you write security and compliance rules as version-controlled code, then enforce them automatically at the pull request or infrastructure-provisioning stage instead of relying on a manual review checklist.

Pre-commit hooks and IDE integrations catch problems before code even reaches a shared branch. A secrets scanner or linter running locally gives a developer feedback in seconds, while the same check running only in CI might not surface for twenty minutes, long after the developer has moved on mentally.

The build pipeline itself needs protecting. Enforce that builds run on trusted, isolated runners, that build scripts can't be modified by an untrusted pull request, and that only specific service accounts can push to production registries. Google Cloud's shift-left guidance recommends pairing these guardrails with SBOM generation and progressive rollout strategies to reduce deployment risk without slowing every release to a crawl.

Noise is the real threat to adoption. Palo Alto Networks notes that effective shift-left programs tune automation to surface only exploitable, in-scope findings, with remediation guidance attached directly in the pull request. A tool that flags two hundred low-severity issues on every commit trains developers to ignore it entirely.

Write security and compliance rules as policy-as-code and enforce them at merge time.
Run secret scanners and linters locally through pre-commit hooks for instant feedback.
Lock build pipelines to trusted runners and restrict who can push to production registries.
Tune scanners to flag only exploitable, in-scope findings with fix guidance attached.
Fold SBOM generation and dependency checks into the same pipeline stage as your other tests.

Secure coding, peer review, and the developer workflow

Most vulnerabilities trace back to a handful of recurring coding mistakes, which is why a short, concrete checklist does more good than a long policy document nobody reads. Validate all input at the boundary, use parameterized queries or an ORM instead of string-concatenated SQL, and standardize on a single, vetted authentication library rather than letting each service roll its own session handling.

Code review should be risk-oriented rather than exhaustive. A reviewer checking every line for style issues will burn out before catching the one authorization bypass that matters. A short checklist (does this touch authentication, does it handle user input, does it change access control) focuses review time where it counts, and OWASP's Security Champions model suggests having at least one reviewer per team trained to spot these patterns specifically.

IDE and CI integrations close the loop. Linters with security rule sets, autofix suggestions for common patterns, and dependency checks that run on every pull request mean a developer rarely has to context-switch to a separate security tool.

Secrets management deserves its own line item: use a managed secret store (Vault, AWS Secrets Manager, or a cloud provider's equivalent) instead of environment files or hard-coded strings, and rotate credentials on a schedule rather than only after an incident.

Validate input at the boundary and use parameterized queries everywhere data touches a database.
Standardize on one vetted authentication and session-handling library across services.
Run risk-oriented code review focused on authentication, input handling, and access control changes.
Store secrets in a managed vault and rotate them on a schedule, not just after a breach.

Supply-chain hygiene: SBOMs, SCA, and dependency risk

Most modern applications are mostly other people's code, which makes dependency management one of the highest-leverage areas in a secure SDLC. A software bill of materials should list every direct and transitive dependency, its version, and its license, generated automatically at build time rather than maintained by hand in a spreadsheet that goes stale within a week.

Software composition analysis tools scan those dependencies against known vulnerability databases continuously, not just at release time, since new CVEs get published against libraries you already shipped last quarter. The trick to keeping SCA useful is triage: a vulnerable function buried in a code path you never call matters less than a vulnerable function on your authentication flow, and treating every match as equally urgent is how teams stop paying attention.

Dependency policies should set explicit allow and deny lists for known-bad packages, plus an upgrade window (say, patching high-severity dependency issues within a set number of days) so "we'll get to it" doesn't become the permanent answer. Protecting the provenance of your build artifacts matters just as much as scanning the dependencies themselves; adopting SLSA-style provenance guarantees that what you tested is actually what you shipped.

Generate SBOMs automatically at build time, including transitive dependencies and license data.
Run SCA continuously against your dependency tree, not only at release.
Triage dependency alerts by exploitability and exposure before assigning remediation priority.
Set explicit allow/deny lists and a maximum patch window for high-severity dependency issues.

Choosing the right testing mix: SAST, DAST, IAST, and manual pentests

No single testing type catches everything, and layering different approaches is what mature programs actually do. Static analysis (SAST) runs directly in the IDE and on every pull request, catching insecure patterns before code merges, which is the cheapest place to find a bug.

Software composition analysis runs continuously against your dependency graph, validating SBOM accuracy alongside vulnerability checks. Dynamic analysis (DAST) needs a running application, so it belongs in staging or a pre-release environment where it can exercise actual requests and responses the way an attacker would.

Interactive analysis (IAST) and runtime application self-protection (RASP) sit a level above DAST: IAST instruments the running application for higher-fidelity findings during QA, while RASP can actively block certain attack patterns in production when the risk tolerance calls for it. Neither replaces the earlier layers; they add depth for applications handling sensitive data or facing regulatory scrutiny.

Periodic manual penetration testing and red-team exercises remain necessary because automated tools are weak at business logic flaws: a workflow that lets a user escalate privileges through a sequence of valid API calls won't trip a scanner, but it will trip an experienced tester.

SAST: run in the IDE and on every pull request for the earliest, cheapest detection.
SCA: run continuously against dependencies and validate SBOM accuracy alongside it.
DAST: run against staging or pre-release environments to catch runtime issues.
IAST/RASP: add for sensitive or regulated applications needing deeper or active protection.
Manual pentests: schedule periodically to catch business logic flaws automation misses.

Governance, metrics, and the roles that keep it running

Secure SDLC practices decay without ownership. The Security Champions model assigns a trained advocate inside each engineering team who triages findings, runs lightweight threat models, and escalates to central application security when needed. Programs stall when champions get the title without real authority: they need dedicated time, a training budget, and a clear escalation path, not just a Slack channel.

Metrics worth tracking include time-to-fix for critical findings, the count of open critical vulnerabilities across your codebase, and a pipeline security score that tracks what percentage of repositories have SAST, SCA, and secret scanning enabled. Fixing vulnerabilities during design or coding costs far less than fixing them after release, according to GitLab's shift-left analysis, which is exactly why time-to-fix matters more as a trend than as a single number.

Governance needs a regular cadence too: quarterly policy review, a documented exception process for findings that can't be fixed immediately, and a short executive report that translates pipeline metrics into business risk language. Pair this with onboarding training for new hires and periodic refreshers for existing teams, since tooling changes faster than most training programs account for.

Appoint a trained Security Champion in each team with real time allocation and escalation authority.
Track time-to-fix, open critical vulnerability count, and pipeline coverage as core metrics.
Review policy and exceptions on a quarterly cadence with a short executive summary.
Onboard new hires on secure coding standards and refresh existing teams periodically.

Triaging and remediating vulnerabilities without stalling delivery

A workable triage framework ranks findings by three factors: exploitability (how easily can this be triggered), exposure (is it internet-facing or internal only), and business impact (what data or function does it touch). A critical finding on an internal admin tool behind VPN ranks differently than the same severity label on a public login page.

Score every new finding against exploitability, exposure, and business impact before assigning a priority.
Set remediation SLAs by severity: hotfix immediately for actively exploited issues, next sprint for everything else rated high.
Backport fixes to supported older versions when a vulnerability affects more than the current release branch.
Automate fixes for simple, low-risk issues like dependency version bumps that pass existing tests.
Re-test and formally close each finding instead of trusting that a code change alone resolved it.

This structure keeps delivery moving because most findings don't need to stop a release, only the small number that are both exploitable and exposed do.

A practical 30/60/90-day rollout plan

Start small and build outward rather than trying to implement every practice above at once.

Days 1 to 7: enable SCA and secret scanning on your main branches; these catch the most common exposures with almost no engineering overhead.
Day 30: integrate SAST into pull request checks, appoint at least one Security Champion per team, and establish a metrics baseline.
Day 60: add policy-as-code checks to your pipeline, start generating SBOMs automatically, and harden build runner permissions.
Day 90: commission a penetration test, verify your remediation workflow closes findings end to end, and publish your first metrics report internally.

Pro Tip: Don't wait for a perfect threat model before enabling SCA and secret scanning: those two controls alone catch a large share of avoidable exposures within the first week.

Earthshaker Security: pairing automation with manual verification

Our approach combines automated scanning with hand-verified testing, which matters most at the point where a secure SDLC program meets its day-90 pentest. Automated tools flag candidates; our testers confirm which findings are actually exploitable and discard the rest, so engineering teams get a report with fewer false positives and clear, actionable fixes written for both developers and non-technical stakeholders. Every confirmed finding includes a re-test once you've shipped the fix, closing the loop your remediation process depends on.

Building incident response into the SDLC

An incident response plan that lives outside the development process arrives too late to be useful. The teams that recover fastest from a production security incident are the ones that treat it as an input back into the SDLC, not a separate fire drill handled entirely by operations.

That means your incident response playbook should name who from engineering gets paged, what logging and monitoring data is already in place to support investigation, and how a confirmed incident becomes a backlog item with the same triage treatment as any other vulnerability finding. Runtime monitoring from the release and operations phase is what actually detects most incidents, so the monitoring you set up for day-to-day operations needs to double as your incident detection layer rather than existing as an afterthought.

After an incident closes, the root cause should feed back into your threat model and your secure coding standards. A flaw that caused a real incident deserves a specific test case added to your SAST or DAST suite, so the same class of bug can't reappear silently in a future release. Treat postmortems as a source of new checklist items, not just a retrospective document that gets filed and forgotten.

Incident response feeding secure development

Privacy and compliance across the SDLC phases

Privacy requirements are easiest to meet when they're decided during requirements gathering rather than retrofitted after a regulator or client asks a question you can't answer. Data classification, covered earlier, is the foundation: knowing which fields are personal, sensitive, or regulated determines what encryption, access logging, and retention rules apply before a single database table is designed.

During design, privacy-by-design principles mean minimizing what personal data you collect in the first place and segmenting it from less sensitive data so a breach in one area doesn't automatically expose everything. During implementation, that translates into concrete controls: field-level encryption for sensitive columns, access logging on anything touching personal data, and consent tracking where the applicable regulation requires it.

Testing should verify these controls actually work, not just that they exist on paper: a DAST run that confirms an unauthorized user genuinely can't retrieve another user's data is worth more than a compliance checklist that says encryption is "enabled." Compliance requirements vary significantly by sector and jurisdiction, so treat any specific legal threshold as something to confirm with counsel or a compliance specialist rather than something to assume from general guidance.

What teams get wrong about shifting left

The most common mistake isn't under-investing in security tooling, it's over-automating too fast and burying developers in low-severity alerts until they tune the whole system out. Alert fatigue kills more secure SDLC programs than missing tools ever do.

A better shortcut: start with two or three high-signal checks, measure whether developers actually act on them, and only add more once those are trusted. Iterate on noise reduction before you add scope, and let your metrics tell you what to fix next instead of guessing.

— caleb

How Earthshaker Security can help you close the gap

We offer penetration testing and security assessment services combining automated scanning with hand-verified findings so you get actionable fixes instead of raw scanner noise. Every engagement fits naturally at the day-90 mark of the rollout plan above: assessment, prioritized fixes, then a re-test to confirm closure.

Earthshaker Security

Our Starter engagement has a one-off fee, and our Retainer plan is available with monthly pricing for teams that want ongoing coverage rather than a single snapshot. Browse our full service catalog or get your pricing details to find the engagement that fits your rollout timeline. If you're also reviewing design or pre-release usability alongside security, a UX audit from Slicer pairs well with a security review during that same pre-release window.

FAQ

What is the difference between SDLC and secure SDLC?

A standard SDLC focuses on building and shipping functional software through phases like requirements, design, coding, testing, and release. A secure SDLC adds security activities, such as threat modeling, secure coding standards, and automated scanning, into each of those same phases instead of treating security as a separate final step.

What are examples of secure coding practices?

Common secure coding practices include validating all input at the system boundary, using parameterized queries instead of string-concatenated SQL, and standardizing on a single vetted authentication library rather than custom session handling. Storing secrets in a managed vault instead of hard-coding them, and running linters with security rule sets on every commit, are also widely recommended.

What are the 7 principles of Secure by Design?

Definitions vary slightly by source, but Secure by Design generally centers on minimizing attack surface, applying secure defaults, defense in depth, least privilege, and fail-safe handling of errors. Rather than treating any single numbered list as canonical, focus on the underlying goal: security decisions baked into architecture before a line of code is written.

What are the 7 phases of SDLC?

Most models describe the SDLC as planning, requirements analysis, design, implementation, testing, deployment, and maintenance, though naming conventions vary across organizations. A secure SDLC maps specific security activities, like data classification in requirements or threat modeling in design, onto each of these same phases.

When should a penetration test happen in the SDLC?

A penetration test typically happens before a major release and periodically afterward, once automated testing (SAST, DAST, SCA) has already caught the more common issues. Running a pentest at this stage catches business logic flaws and chained exploits that automated scanners consistently miss.