Most application vulnerabilities are cheaper to prevent than to patch, and cheaper to patch than to explain to an authorizing official. A secure software development lifecycle (SDLC) moves security decisions to the point where they cost the least: requirements, design, and the build pipeline. This article walks through each phase, the three core testing techniques (SAST, DAST, and SCA), the web application risks they target, and the operational practices that keep a system defensible after release.
Start With a Framework: NIST SSDF
The NIST Secure Software Development Framework (SSDF), published as SP 800-218, is a set of fundamental, technology-neutral practices that can be integrated into any SDLC model.[1] It organizes practices into four groups: Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities. Federal buyers care because OMB memoranda M-22-18 and M-23-16 tie the SSDF to the secure software development attestation that agencies collect from software producers.[2] Even where no attestation is required, the SSDF is a practical checklist for what a mature engineering team should be able to show.
Embedding Security in Each SDLC Phase
Requirements
Write security requirements the same way you write functional ones: testable and traceable. Identify the data types the system handles, the impact level it must be authorized at, and the controls inherited from the hosting platform. Requirements such as "all administrative actions are authenticated with multifactor authentication and logged" can be verified later; "the system shall be secure" cannot.
Design and Threat Modeling
Threat modeling asks four plain questions: what are we building, what can go wrong, what will we do about it, and did we do a good job. Draw the data flows, mark trust boundaries, and walk each boundary with a method such as STRIDE. The output is a short list of design decisions (where authorization is enforced, how secrets are issued, what is logged) and a set of abuse cases that become test cases. OWASP lists Insecure Design as its own category because no amount of clean code fixes a flawed design.[3]
Build
Developers need fast feedback while the change is still fresh. Run static analysis, dependency checks, and secret scanning on every pull request. Require code review, protect the main branch, and build from pinned, verified inputs so the artifact you test is the artifact you ship.
Test
Add dynamic testing against a running instance in a production-like environment, plus targeted manual testing for business-logic and access-control flaws that tools rarely find.
Release
Release is a decision point. Confirm that gate criteria are met, that open findings have documented risk acceptance where required, and that the build is signed or otherwise traceable to its source. Keep a software bill of materials (SBOM) so you can answer "are we affected?" quickly when a new vulnerability is disclosed.
Operate
Security work continues after deployment: patching, configuration management, logging, monitoring, and a documented path for receiving and fixing vulnerability reports. Feed what you learn back into requirements and design.
SAST, DAST, and SCA: What Each One Catches
These techniques are complementary. None replaces the others.
- Static application security testing (SAST) analyzes source code or bytecode without running it. It is good at finding injection-prone code paths, unsafe API use, and hard-coded credentials early, with a pointer to the exact line. It can produce false positives and cannot see runtime configuration or deployed-environment behavior.
- Dynamic application security testing (DAST) probes a running application from the outside, the way an attacker would. It can find server misconfiguration, missing security headers, authentication and session weaknesses, and some injection flaws. It does not know where in the code a problem lives and only covers what it can reach.
- Software composition analysis (SCA) inventories third-party and open-source components and matches them against known vulnerability data and license rules. It catches known-bad dependencies, including transitive ones, but says nothing about flaws in your own code.
Interactive testing (IAST), manual code review, and fuzzing add further coverage where the risk justifies the effort.
Web Application Risks and Mitigations
The OWASP Top 10 is an awareness document that ranks the most critical web application security risks. The categories below follow the 2021 edition; check OWASP for the current edition when you plan your program.[3]
- Broken access control: deny by default, enforce authorization on the server for every request, and test object and function-level permissions explicitly.
- Cryptographic failures: use TLS everywhere, current vetted algorithms, and a managed key service. Do not invent cryptography.
- Injection: use parameterized queries and safe APIs, validate input against an allow-list, and encode output for its context.
- Insecure design: threat model early and reuse proven secure design patterns.
- Security misconfiguration: use hardened, repeatable baselines and remove default accounts, sample content, and verbose error output.
- Vulnerable and outdated components: maintain an inventory, scan with SCA, and patch on a defined schedule.
- Identification and authentication failures: require multifactor authentication, rate-limit attempts, and protect session identifiers.
- Software and data integrity failures: verify signatures and sources for updates and dependencies, and secure the CI/CD pipeline itself.
- Logging and monitoring failures: log security events with enough context to investigate, protect the logs, and alert on what matters.
- Server-side request forgery (SSRF): validate and restrict outbound destinations and segment the network so a compromised app cannot reach internal services freely.
Secure Coding Principles and Secrets Management
A short set of habits prevents a large share of defects: validate all input at trust boundaries, encode output, apply least privilege to code and service accounts, fail closed, keep error messages free of internal detail, and prefer well-maintained framework features over custom security code. Document the standard your teams follow and enforce it with linters and review checklists.
Secrets deserve their own rule: they never live in source code, container images, or build logs. Store them in a dedicated secrets manager, issue short-lived credentials where possible, scope each one narrowly, rotate on a schedule and after any suspected exposure, and run secret scanning in pre-commit hooks and CI. The OWASP Secrets Management Cheat Sheet is a good reference. Treat any secret that reached a repository as compromised, even if the commit was later removed.
CI Gating: Make the Pipeline Enforce the Policy
Findings that nobody is forced to act on pile up. Define machine-enforceable gate criteria and fail the build when they are not met. A reasonable starting policy is to block merges on new high and critical findings from SAST and SCA, on any detected secret, and on failed signature or provenance checks. Medium and lower findings create tracked tickets with due dates rather than blocking. Keep an exception process with an owner, an expiry date, and a recorded justification, so a gate is never simply switched off. Tune rules to cut false positives, because a noisy gate trains developers to ignore it.
OS and Container Hardening, Patch and Configuration Management
Application security sits on top of a platform that must also be defensible. Start from published baselines such as the CIS Benchmarks or DISA STIGs, apply them through automation rather than by hand, and detect drift. For containers, follow NIST SP 800-190: use minimal base images, scan images in the pipeline, run as a non-root user, drop unneeded capabilities, keep images immutable, and never bake secrets into layers.[4]
Patch management is an inventory problem first. You cannot patch what you cannot see, so keep an asset and component inventory, prioritize by exposure and exploitability, and use the CISA Known Exploited Vulnerabilities Catalog as a signal for what to fix first. NIST SP 800-40 Rev. 4 describes enterprise patch management planning.[5] Track configuration changes through version control and change approval so every production change is attributable.
Building a Penetration Testing Program
Penetration testing validates that controls work against a determined, creative tester. NIST SP 800-115 provides technical guidance on planning and conducting security tests.[6]
Scoping and Rules of Engagement
Define in writing which systems, environments, and techniques are in scope, which are off limits, the testing window, the data-handling rules, and the emergency stop procedure. Name points of contact on both sides and agree how critical findings are reported mid-test rather than at the end.
Legal Considerations
Testing without authorization can violate laws such as the Computer Fraud and Abuse Act. Obtain written authorization from the system owner, and confirm that third parties are covered: cloud providers publish their own testing policies, and shared services or interconnected systems may need separate approval. Involve legal counsel and the authorizing official early, and plan for how any sensitive or regulated data encountered during testing will be handled.
Before, During, and After
- Before: confirm backups and rollback plans, notify the monitoring team or deliberately decide to run unannounced, and verify that test accounts and environments are ready.
- During: log activity, keep within scope, and escalate anything that suggests real compromise or an immediate risk to production.
- After: remove test accounts, tools, and artifacts, and securely store or destroy collected evidence.
Reporting and Retest
A useful report ranks findings by risk, includes reproduction steps and evidence, and gives specific remediation advice that engineers can act on. Assign every finding an owner and a due date, then retest to confirm the fix works. A finding is not closed until retest evidence says so.
Vulnerability Management SLAs
A service-level agreement turns "we will fix it" into a commitment. Define remediation windows by severity, shorten them for vulnerabilities that are known to be exploited or that sit on internet-facing systems, and measure performance. Where your program is subject to agency requirements, such as CISA Binding Operational Directive 22-01 for catalog entries, use the dates those documents set.[7] Otherwise, set windows that your team can realistically meet and that your authorizing official accepts, and document the exception path for findings that cannot be fixed in time (compensating controls, a plan of action and milestones, and a named risk owner).
Key Takeaways
- Use NIST SSDF (SP 800-218) as the backbone and map practices to each SDLC phase.
- SAST, DAST, and SCA find different problems. Use all three, plus manual testing for logic and access control.
- Threat model during design and turn abuse cases into tests.
- Keep secrets out of code and images, and scan for them in CI.
- Gate builds on high-severity findings and manage exceptions with owners and expiry dates.
- Harden platforms from published baselines, automate patching, and track drift.
- Run penetration tests under written authorization, report clearly, and retest.
- Set vulnerability remediation SLAs by severity and exploitability, and measure them.
Conclusion
A secure SDLC is less about any single tool than about a repeatable system: clear requirements, early threat modeling, layered automated testing, enforced gates, hardened platforms, disciplined penetration testing, and measured remediation. Teams that build these habits produce software that is easier to authorize and easier to defend. This article is general guidance and does not replace your agency's policies or an assessment of your specific system.
References
- NIST, "Secure Software Development Framework (SSDF) Version 1.1," SP 800-218, February 2022. https://csrc.nist.gov/pubs/sp/800/218/final
- CISA, "Secure Software Development Attestation Form," and OMB memoranda M-22-18 and M-23-16. https://www.cisa.gov/secure-software-attestation-form
- OWASP, "OWASP Top 10." https://owasp.org/www-project-top-ten/
- NIST, "Application Container Security Guide," SP 800-190. https://csrc.nist.gov/pubs/sp/800/190/final
- NIST, "Guide to Enterprise Patch Management Planning," SP 800-40 Rev. 4. https://csrc.nist.gov/pubs/sp/800/40/r4/final
- NIST, "Technical Guide to Information Security Testing and Assessment," SP 800-115. https://csrc.nist.gov/pubs/sp/800/115/final
- CISA, "BOD 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities." https://www.cisa.gov/news-events/directives/bod-22-01-reducing-significant-risk-known-exploited-vulnerabilities
