{"id":7007,"date":"2026-10-09T14:19:00","date_gmt":"2026-10-09T14:19:00","guid":{"rendered":"https:\/\/krylosecurity.com\/blog\/?p=5012"},"modified":"2026-10-27T11:23:45","modified_gmt":"2026-10-27T11:23:45","slug":"penetration-testing-in-the-sdlc","status":"publish","type":"post","link":"https:\/\/krylosecurity.com\/blog\/penetration-testing-in-the-sdlc\/","title":{"rendered":"Penetration Testing in SDLC: Where It Fits and How to Use the Results"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">Penetration testing in SDLC means testing your software the way an attacker would at defined points in the software development lifecycle, then feeding what the testers find back into how you plan, design and build. Done once, at the end, it finds bugs. Done as part of the secure software development lifecycle (SSDLC), it shows you which steps in your process keep letting vulnerabilities through, so you can fix the process as well as the code.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">This guide covers where penetration testing fits at each stage, how it maps to the NIST Secure Software Development Framework, and eight proven ways to turn a pentest report into fewer vulnerabilities next time.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">What is penetration testing in SDLC?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">A penetration test is an authorised, simulated attack on an application or system. Penetration testing in SDLC does three jobs:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>It finds vulnerabilities<\/strong> that design reviews, code reviews and automated scanners missed.<\/li>\n\n\n\n<li><strong>It checks that security controls work<\/strong> as intended under real attack conditions.<\/li>\n\n\n\n<li><strong>It measures the development process itself.<\/strong> Every finding points to a stage where the issue could have been prevented or caught earlier.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">The third job is the one most teams skip, and it is where most of the value is.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Penetration testing in SDLC, stage by stage<\/h2>\n\n\n\n<figure class=\"wp-block-image size-large\"><img decoding=\"async\" src=\"https:\/\/krylosecurity.com\/blog-images\/penetration-testing-in-sdlc\/penetration-testing-in-sdlc-stages.jpg\" alt=\"Penetration testing in SDLC: what to do at each stage from planning to maintenance\"\/><\/figure>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th>SDLC stage<\/th><th>What penetration testing contributes<\/th><\/tr><\/thead><tbody><tr><td>Planning and requirements<\/td><td>Findings from past tests become security requirements and abuse cases for new features.<\/td><\/tr><tr><td>Design<\/td><td>Testers review risky designs (authentication, payments, multi-tenancy) before code is written, informed by threat modelling.<\/td><\/tr><tr><td>Development<\/td><td>Developers use past findings as a checklist; automated security tests in the pipeline catch known issue types.<\/td><\/tr><tr><td>Testing and verification<\/td><td>A full penetration test of the release candidate, usually grey box with accounts at every role.<\/td><\/tr><tr><td>Release and deployment<\/td><td>A focused test of anything changed late; critical issues block the release.<\/td><\/tr><tr><td>Maintenance<\/td><td>Yearly tests plus tests after significant changes; findings feed back into planning.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">The pattern is a loop, not a line. The most valuable penetration testing in SDLC feeds each finding back to the earliest stage that could have stopped it.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">How it maps to the NIST Secure Software Development Framework<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The US National Institute of Standards and Technology publishes the <a href=\"https:\/\/csrc.nist.gov\/pubs\/sp\/800\/218\/final\" target=\"_blank\" rel=\"noreferrer noopener nofollow\">Secure Software Development Framework (SSDF), SP 800-218<\/a>, which many customers and regulators now use to judge how software is built. It groups practices into four areas, and penetration testing supports all of them:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Prepare the Organization (PO):<\/strong> findings show where training, tools and policies need to change.<\/li>\n\n\n\n<li><strong>Protect the Software (PS):<\/strong> testing confirms that code, secrets and build systems are protected.<\/li>\n\n\n\n<li><strong>Produce Well-Secured Software (PW):<\/strong> the framework calls for testing executable code to find vulnerabilities, which is exactly what a penetration test does.<\/li>\n\n\n\n<li><strong>Respond to Vulnerabilities (RV):<\/strong> analysing root causes of findings, so whole classes of issue stop recurring.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">OWASP&#8217;s <a href=\"https:\/\/owaspsamm.org\/\" target=\"_blank\" rel=\"noreferrer noopener nofollow\">Software Assurance Maturity Model (SAMM)<\/a> takes a similar approach and is a practical way to measure progress year to year.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Why automated testing is not enough on its own<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Automated security testing belongs in every pipeline. Static analysis (SAST) catches insecure code patterns, dynamic scanning (DAST) catches common runtime issues, and dependency scanning catches known vulnerable libraries. They are fast and repeatable.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">What they cannot do:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>tell that one customer is reading another customer&#8217;s data, because the response looks normal,<\/li>\n\n\n\n<li>understand your business rules, such as &#8220;a discount code works once&#8221;,<\/li>\n\n\n\n<li>chain three low-severity issues into one serious breach.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Human penetration testers find these, which is why penetration testing in SDLC remains essential even with good tooling. Read <a href=\"https:\/\/krylosecurity.com\/blog\/broken-access-control-examples\/\">broken access control examples<\/a> for the most common case.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">8 proven ways to use pentest results in the SSDLC<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">These strategies turn a penetration test from a one-off bug list into lasting improvement.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1. Run a blameless review of every finding<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">For each finding, ask one question: at which stage of the SDLC should this have been caught, and why was it not? Record the answer. After two or three tests, patterns appear, and those patterns tell you what to fix in your process.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">2. Update policies and standards<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Write it down: security defects in production are not acceptable, and high-severity findings block releases. Fund the training and tooling that make this realistic, and have senior leadership approve and enforce the policy.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">3. Turn findings into security requirements<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Write reusable, testable security requirements that cover the <a href=\"https:\/\/krylosecurity.com\/blog\/owasp-top-10-2025\/\">OWASP Top 10:2025<\/a>. When a test finds a defect, add a user story and acceptance criteria that would have prevented it, so the same mistake cannot pass review again.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">4. Train developers on what was actually found<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Generic security training rarely changes code. Training built on your own findings does. If a test finds a flaw your training does not cover, the training failed, not the developer. Update it.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">5. Improve threat modelling and design review<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Use findings to update threat modelling checklists with the design decisions that would have prevented each fault. Create secure design patterns, such as one central authorisation layer, that rule out whole classes of defect.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">6. Add the right automated tests to the pipeline<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Once a test finds a class of issue, add a check that catches it automatically: a SAST rule for the insecure pattern, a DAST check for the misconfiguration, or a unit test that tries user B&#8217;s data with user A&#8217;s session.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">7. Add security cases to QA<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">QA teams already test edge cases. Give them security edge cases from your findings: negative quantities, repeated coupon codes, skipped workflow steps. They catch logic flaws that scanner rule sets miss.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">8. Gate releases on risk<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Build checks into the release process that stop known classes of flaw moving further down the SDLC. A critical finding in a pre-release penetration test should block the release until it is fixed and retested.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">A worked example<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">A typical SaaS team, illustrative but common, ships every two weeks and has a penetration test once a year.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>The first test<\/strong> finds 14 issues. Five are access control flaws where one tenant can see another tenant&#8217;s records.<\/li>\n\n\n\n<li><strong>The blameless review<\/strong> finds the cause: each developer writes their own tenant filter in each query, and code review does not check for it.<\/li>\n\n\n\n<li><strong>The fix to the process:<\/strong> a shared data access layer that applies the tenant filter automatically, a design pattern for new endpoints, and an automated test that runs every endpoint with accounts from two tenants.<\/li>\n\n\n\n<li><strong>The next test<\/strong>, a year later, finds no tenant isolation issues at all, and the testers spend their time on harder problems.<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">The first test found 14 bugs. The changes it prompted prevented a whole class of them for good.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Penetration testing in SDLC for agile and DevOps teams<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Teams that ship every week cannot wait a year between tests, and they cannot stop every release for a two-week engagement. The answer is to split the work by risk and by speed:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Every commit:<\/strong> automated checks in the pipeline, such as SAST, dependency scanning and secret scanning. These are fast and catch known patterns.<\/li>\n\n\n\n<li><strong>Every sprint:<\/strong> developers check new endpoints against your access control rules, using the findings from past tests as their checklist.<\/li>\n\n\n\n<li><strong>Every risky feature:<\/strong> a short, focused penetration test before or just after launch. Anything that touches login, payments, permissions or personal data qualifies. Two or three days is often enough.<\/li>\n\n\n\n<li><strong>Every year:<\/strong> a full grey box penetration test of the whole application, so you see how features interact and nothing slips between the focused tests.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">This keeps penetration testing in SDLC proportional. The pipeline handles volume, testers handle judgement, and nothing that matters ships untested for long.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Who owns what<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Developers<\/strong> own fixes, and the automated tests that stop each class of issue coming back.<\/li>\n\n\n\n<li><strong>The security lead or engineering manager<\/strong> owns the blameless review, the testing calendar and the policy on what blocks a release.<\/li>\n\n\n\n<li><strong>The penetration testers<\/strong> own finding what everyone else missed, and explaining it clearly enough to fix.<\/li>\n\n\n\n<li><strong>Product managers<\/strong> own the abuse cases, because they know how a feature is supposed to be used, and so how it could be misused.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Common mistakes with penetration testing in SDLC<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Testing only right before launch.<\/strong> There is no time to fix design-level issues, so they ship anyway with a promise to fix them later.<\/li>\n\n\n\n<li><strong>Testing a different build from the one that ships.<\/strong> If major changes land after the test, the report describes software your customers never use.<\/li>\n\n\n\n<li><strong>Fixing the instance, not the cause.<\/strong> Patching one vulnerable endpoint while ten others use the same pattern means the next test finds the same issue again.<\/li>\n\n\n\n<li><strong>Treating the report as the finish line.<\/strong> The value is in the follow-up: tickets, process changes and a retest that proves the fixes work.<\/li>\n\n\n\n<li><strong>Black box testing a logged-in product.<\/strong> Without accounts at each role, testers spend their time outside the login page and miss the access control flaws that matter most. Read <a href=\"https:\/\/krylosecurity.com\/blog\/black-box-grey-box-white-box-penetration-testing\/\">black box vs grey box vs white box testing<\/a>.<\/li>\n\n\n\n<li><strong>No owner for findings.<\/strong> A report emailed to a shared inbox is a report nobody fixes.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">How often to test during the SDLC<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>A full penetration test at least once a year,<\/strong> and before major releases.<\/li>\n\n\n\n<li><strong>Focused tests<\/strong> whenever a release touches authentication, payments, permissions or personal data.<\/li>\n\n\n\n<li><strong>Automated scanning continuously<\/strong> in the pipeline.<\/li>\n\n\n\n<li><strong>A retest<\/strong> after each round of fixes, to confirm they work.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">For a fuller schedule, read <a href=\"https:\/\/krylosecurity.com\/blog\/how-often-penetration-testing\/\">how often to run a penetration test<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Checklist: is penetration testing built into your SDLC?<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Penetration tests are scheduled around releases, not only by the calendar.<\/li>\n\n\n\n<li>Every finding has an owner and a due date in your ticket system.<\/li>\n\n\n\n<li>Each finding is traced back to the SDLC stage that should have caught it.<\/li>\n\n\n\n<li>Recurring findings change training, requirements or design patterns.<\/li>\n\n\n\n<li>Automated checks are added for each class of issue found.<\/li>\n\n\n\n<li>Critical and high findings block releases until retested.<\/li>\n\n\n\n<li>Results feed the next year&#8217;s threat model and test scope.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">The limits of penetration testing<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">A penetration test covers a defined scope in a fixed time. It cannot show every training need, every compliance gap or every vulnerability in code paths it did not reach. It works best as one part of a security programme that also includes secure design, code review, automated testing and monitoring.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Frequently asked questions<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">At what stage of the SDLC is penetration testing done?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Most often in the testing and verification stage, before a major release, and periodically during maintenance. The best results come from also feeding findings back into planning and design, so penetration testing in SDLC becomes a loop rather than a single step.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What is the difference between SDLC and SSDLC?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The SDLC is the process of planning, designing, building, testing, releasing and maintaining software. The secure software development lifecycle (SSDLC) adds security activities to every stage: security requirements, threat modelling, secure coding, security testing and vulnerability response.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Is penetration testing part of DevSecOps?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Yes. In DevSecOps, automated security checks run in the pipeline on every change, and penetration tests run around major releases and on a schedule. The findings from manual testing become new automated checks.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Can penetration testing replace code review?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">No. Code review looks at all the code for weaknesses. A penetration test checks which weaknesses can actually be exploited in the running application. They complement each other.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Make penetration testing part of your SDLC<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Krylo Security tests <a href=\"https:\/\/krylosecurity.com\/services\/web-application-penetration-testing\">web applications<\/a> and <a href=\"https:\/\/krylosecurity.com\/services\/api-penetration-testing\">APIs<\/a> around your release cycle, with every finding reproduced by a tester and a fix written for your stack. <a href=\"https:\/\/krylosecurity.com\/contact\">Book a free scoping call<\/a> to plan testing around your next release.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Security works best when it is built in, not bolted on. This is where penetration testing fits in the secure software development lifecycle, one vulnerability at a time.<\/p>\n","protected":false},"author":1,"featured_media":6012,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[44],"tags":[76,6,75,9],"class_list":["post-7007","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-penetration-testing","tag-application-security","tag-penetration-testing","tag-secure-development","tag-ssdlc"],"_links":{"self":[{"href":"https:\/\/krylosecurity.com\/blog\/wp-json\/wp\/v2\/posts\/7007","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/krylosecurity.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/krylosecurity.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/krylosecurity.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/krylosecurity.com\/blog\/wp-json\/wp\/v2\/comments?post=7007"}],"version-history":[{"count":2,"href":"https:\/\/krylosecurity.com\/blog\/wp-json\/wp\/v2\/posts\/7007\/revisions"}],"predecessor-version":[{"id":7094,"href":"https:\/\/krylosecurity.com\/blog\/wp-json\/wp\/v2\/posts\/7007\/revisions\/7094"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/krylosecurity.com\/blog\/wp-json\/wp\/v2\/media\/6012"}],"wp:attachment":[{"href":"https:\/\/krylosecurity.com\/blog\/wp-json\/wp\/v2\/media?parent=7007"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/krylosecurity.com\/blog\/wp-json\/wp\/v2\/categories?post=7007"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/krylosecurity.com\/blog\/wp-json\/wp\/v2\/tags?post=7007"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}