Blog

<p>AI coding assistants are becoming part of everyday development, raising new questions about trust, security, and code quality. This month, we're exploring how to keep security embedded in every AI-assisted workflow.</p><h2>Security spotlight: Bring Kiuwan into your AI coding assistant</h2><p>AI-assisted development is moving security closer to the moment code is written. <strong>Kiuwan can now run directly through AI coding assistants like Claude Code, Cursor, Codex, Copilot, and Gemini, </strong>so you can scan code and remediate vulnerabilities without leaving your existing workflow.</p><p>Instead of relying on an AI model to determine what is or isn't secure, remediation is grounded in Kiuwan's security analysis and findings. You can get help fixing issues in the IDE, while results flow into your Kiuwan account for centralized visibility and tracking.</p><p><a data-mce-href="https://support.kiuwan.com/hc/en-us/articles/48278088207761-Kiuwan-for-AI-Coding-Assistants/?utm_source=partners_website&amp;utm_medium=partners&amp;utm_campaign=dube&amp;utm_term=&amp;utm_content=ai_integration" href="https://support.kiuwan.com/hc/en-us/articles/48278088207761-Kiuwan-for-AI-Coding-Assistants/?utm_source=partners_website&amp;utm_medium=partners&amp;utm_campaign=dube&amp;utm_term=&amp;utm_content=ai_integration" target="_blank" rel="noopener">Explore the AI Integration in the Kiuwan User Guide</a></p><p><a data-mce-href="https://github.com/kiuwan/qaking-skill" href="https://github.com/kiuwan/qaking-skill" target="_blank" rel="noopener">Get the Skills and Setup Instructions on GitHub</a></p><h2>Security news from around the web</h2><p>🤖<strong> AI coding adoption is soaring… but trust isn't</strong>. <a data-mce-href="https://www.darkreading.com/application-security/ai-coding-security-risks-productivity-gains" href="https://www.darkreading.com/application-security/ai-coding-security-risks-productivity-gains" target="_blank" rel="noopener">Dark Reading reports</a> that enterprise use of AI-generated code has reached 97%, but 96% of respondents don't trust it to be correct as-is. Yet, only 48% of developers say they always review it before committing.</p><p>🧠 <strong>The ability to evaluate AI-written code is becoming more important.</strong> According to <a data-mce-href="https://www.theguardian.com/technology/ng-interactive/2026/jul/12/software-developers-engineers-ai" href="https://www.theguardian.com/technology/ng-interactive/2026/jul/12/software-developers-engineers-ai" target="_blank" rel="noopener">The Guardian</a>, some software engineers are doubling down on fundamentals and adapting their skills, with human judgment playing an increasingly important role in reviewing what AI produces.</p><p>💻 <strong>Software development hiring may be starting to rebound</strong>. <a data-mce-href="https://www.cio.com/article/4195780/it-hiring-sees-a-boost-as-software-development-jobs-slowly-bounce-back.html" href="https://www.cio.com/article/4195780/it-hiring-sees-a-boost-as-software-development-jobs-slowly-bounce-back.html" target="_blank" rel="noopener">CIO reports</a> that U.S. software development job postings have risen 15%, even as overall job postings declined 7%. The recovery comes from a low starting point, but it suggests employers are renewing their search for technical talent as major technology initiatives move forward.</p><h2>Community insights: More code is putting security workflows to the test</h2><p>The <strong>2026 Sembi Software Quality Pulse Report</strong>, which is based on responses from nearly 3,800 software professionals, found that <strong>53% of code is now AI-generated or AI-assisted</strong>. However, only <strong>9% of security teams report fully integrated toolchains with DevOp</strong>s, and just <strong>51% of detected security issues are true positives</strong>.</p><p>Taken together, those findings point to a growing workflow challenge: more code is moving through security processes that are often disconnected and already generating significant noise. This means that as development volume grows, the ability to prioritize meaningful findings and get them into developers' hands fast is just as important as detecting them in the first place.</p><p><a data-mce-href="https://dbinsights.co.za/get-pulse-quality-report" href="https://dbinsights.co.za/get-pulse-quality-report" target="_blank" rel="noopener">Get the Full Report</a></p><h2>Before you go: See how Kiuwan and PreEmptive work</h2><p>Every week, we host live product demos where you can see exactly how Kiuwan and <a data-mce-href="https://dbinsights.co.za/security-solutions/preemptive" href="https://dbinsights.co.za/security-solutions/preemptive" target="_blank" rel="noopener">PreEmptive</a> work. Whether you're exploring these tools for the first time or looking for ways to do more with them, you'll see practical workflows designed to help you work more efficiently and strengthen application security.</p><p>It's a fantastic chance to learn directly from our product specialists. Bring your questions, see the tools in action, and get expert-level instruction that you can put to work right away.</p><p><a data-mce-href="https://dbinsights.co.za/home-book-demo" href="https://dbinsights.co.za/home-book-demo" target="_blank" rel="noopener">Enquire about the next demo or book a demo yourself.</a></p><p><br data-mce-bogus="1"></p>

The Next Step for AI Coding: Built-In Security

<p>Vulnerability testing is the backbone of a modern security program. It helps you proactively find and fix weaknesses across applications, networks, cloud services, and devices, so you can protect your assets and data before attackers get to them.</p><p>Whether you manage a lean startup stack or a sprawling enterprise environment, regular vulnerability testing reduces risk, speeds incident response, and hardens your security posture over time.</p><h2>What is vulnerability testing?</h2><p>Vulnerability testing is a continuous practice to uncover vulnerabilities in systems, applications, and infrastructure. It uses automated tools like network and web scanners, targeted manual checks, and validation to confirm true risk and guide remediation.</p><p>The main outputs of vulnerability testing are vulnerability reports listing the identified vulnerabilities, their severity, and potential impact. They usually have a CVSS score that shows each vulnerability’s impact and likelihood of exploitation.</p><p>Application Security (AppSec) teams can then use the findings in the reports to create an actionable path to reduce the real-world attack surface.</p><p>Ultimately, the goals of vulnerability testing are:</p><ul><li>Building an accurate inventory of assets and exposures.<br></li><li>Detecting known weaknesses and misconfigurations early.<br></li><li>Prioritizing issues by severity, exploitability, and business impact.<br></li><li>Driving timely remediation (patching, configuration changes, or compensating controls).<br></li><li>Tracking key performance indicators (KPIs).<br></li><li>Demonstrating risk reduction to leadership and auditors.</li></ul><h2>Vulnerability scanning vs penetration testing: Key differences</h2><p>Vulnerability scanning and penetration testing are often mentioned together, but they serve distinct roles in a mature security program:</p><h3>Vulnerability scanning</h3><p><strong>&nbsp;Vulnerability scanning</strong> is a proactive, high-level automated process that continuously scans systems, applications, and networks for known weaknesses. It’s designed to find and flag vulnerabilities before they’re exploited, such as outdated software, open ports, missing patches, or misconfigurations. Think of it as a wide-angle lens: it captures everything in view, prioritizes findings by severity, and helps security teams stay on top of emerging risks. Scanning is especially useful for maintaining ongoing visibility, checking compliance boxes, and catching common exposures early in the lifecycle.</p><h3>Penetration testing</h3><p><strong>Penetration testing</strong> (pen testing) or ethical hacking takes things further. Instead of just finding vulnerabilities, pen testers actively try to exploit them in a controlled, authorized way. The goal is to see how far an attacker could get, what data they could access, and how defenses would respond. Pen testing can be manual, automated, or hybrid, depending on scope and complexity.</p><p>Despite their differences, vulnerability scanning and penetration testing complement each other. Scanning provides a continuous view of weaknesses in your system, while pen testing assesses which vulnerabilities are truly exploitable and how threat actors could abuse them.</p><h2>Benefits of vulnerability testing: Why it matters</h2><p>Vulnerability testing isn’t just checking a box for leadership. It’s how organizations stay a step ahead of attackers. Since threats evolve daily, vulnerability testing should be an ongoing habit, not an annual or quarterly event. Each scan strengthens visibility and keeps defenses aligned with emerging risks.</p><p>When done consistently, vulnerability testing gives you many benefits, including understanding your attack surface and strengthening overall trust. Below are the key benefits that show why this practice matters.</p><h3>Understand the attack surface</h3><p>Vulnerability testing provides a comprehensive view of every system, endpoint, and application in your environment. Your team can then identify what assets exist, how they connect, and how attackers might exploit them. That way, they can address exposure before it turns into risk.</p><h3>Prevent security breaches</h3><p>Continuous testing means you can catch weaknesses early, which means it’s less likely for them to get exploited. This practice also supports stronger controls, better security policies, and more effective employee training, all of which further reduce the chance of a successful attack.</p><h3>Prioritize fixes</h3><p>Testing results highlight which vulnerabilities pose the highest risk so your team can focus on what matters most. By prioritizing remediation based on severity and exploitability, you spend time fixing issues that protect the most valuable assets.</p><h3>Meet regulatory requirements</h3><p>Regular vulnerability assessments satisfy compliance standards such as the Payment Card Industry Data Security Standard (PCI DSS), the Health Insurance Portability and Accountability Act of 1996 (HIPAA), ISO 27001, and the Federal Information Security Modernization Act (FISMA).&nbsp;</p><p>They show regulators and clients that your organization takes data protection seriously and follows industry best practices.</p><h3>KPI tracking</h3><p>Testing generates data that helps measure progress. Metrics such as mean time to remediate or percentage of critical issues closed give executives a clear view of how security initiatives perform over time.</p><h3>Reduced downtime and costs</h3><p>Fixing vulnerabilities early prevents disruptions later. Proactive testing helps avoid the financial and operational costs of recovery efforts after a breach.</p><h3>Stronger safety culture</h3><p>Regular testing reinforces that security is part of everyone’s job. It encourages developers, administrators, and executives alike to integrate secure thinking into daily operations and decision-making.</p><h3>Increased trust</h3><p>A consistent vulnerability testing program demonstrates to customers, investors, and partners that you actively hunt for and address risks before they cause harm, rather than waiting for attacks to occur. This level of commitment to security builds lasting confidence and sets your organization apart in a flooded market.</p><h2>What is the process for vulnerability testing?</h2><p>Vulnerability testing has a clear, repeatable process. Here’s how each step works.</p><h3>1. Define testing goals</h3><p>Start by asking yourself what your goals are. Are you aiming to protect specific applications? Or are you verifying compliance and reducing overall attack surface? Clear goals help you focus on high-value assets. It also helps you make the testing process match your organization’s broader security objectives.</p><h3>2. Determine which assets to scan</h3><p>Create a complete inventory of assets, including servers, endpoints, web apps, APIs, databases, and cloud services. A clear view of your environment prevents blind spots and ensures that testing covers both internal and external systems.</p><h3>3. Use a vulnerability scanning tool</h3><p>Run an automated vulnerability scanner to detect known weaknesses such as missing patches, open ports, or insecure configurations. These tools crawl systems efficiently and compare findings against up-to-date vulnerability databases.&nbsp;</p><p>Consider running manual penetration tests for complex or business-logic flaws that automated tools might miss.</p><h3>4. Read the report and prioritize next steps</h3><p>After scanning, review the generated report carefully. Analyze each finding by its severity, potential impact, and likelihood of exploitation. First, focus on vulnerabilities that expose sensitive data or critical systems. To maintain accountability, assign owners, set service-level agreements (SLAs), and track remediation progress.</p><h3>5. Remediate vulnerabilities</h3><p>Address identified vulnerability remediation issues through patching, configuration changes, or compensating controls. Tackle the most critical threats first and verify that each fix works as intended.</p><h3>6. Continue testing</h3><p>Schedule regular scans and retests to confirm that fixes hold and that new vulnerabilities haven’t appeared. This helps you measure progress, strengthen resilience, and maintain a clear picture of your organization’s security posture over time.</p><h2>What tools do you use for vulnerability testing?</h2><p><br>Vulnerability testing tools are services or applications that help you spot and assess security weaknesses in your systems, networks, and apps. Depending on your needs and environment, you can use a combination of the following tools.</p><h3>Network vulnerability scanners</h3><p>Network scanners probe IP ranges and hosts for open ports, weak services, default credentials, and missing patches. Running them regularly helps you maintain an up-to-date list of exposed services and spot hygiene problems early. As a result, you get fast, repeatable visibility into infrastructure risks and compliance gaps.</p><h3>Web application scanners</h3><p>Web scanners crawl sites and APIs to identify SQL injection, cross-site scripting, broken authentication, and other web-specific flaws. They handle authenticated scans and common attack patterns so QA or security teams can triage issues before releases. Using them early in the release cycle lets you fix web-specific flaws quickly and reduce production risk.</p><h3>Database scanners</h3><p>Database scanners review permissions, detect insecure defaults, flag outdated versions, and assess risky configurations. They help you protect critical data stores and enforce least-privilege access, reducing the risk of data leaks from misconfigured or unpatched databases.</p><h3>Wireless network scanners</h3><p>Wireless scanners detect unauthorized access points, weak encryption, and Wi-Fi misconfigurations. Regular scans across offices and facilities prevent intruders from establishing local footholds and close an often-overlooked path for lateral movement.</p><h3>Static application security testing (SAST) tools</h3><p>SAST tools analyze source code or compiled code without running the app. They flag hardcoded secrets, insecure libraries, tainted data flows, and unsafe API usage. Integrating SAST into pull request checks and CI pipelines helps developers fix issues, reducing remediation time and costs.</p><h3>Dynamic application security testing (DAST) tools</h3><p>DAST tools interact with running applications to detect runtime issues such as session problems, insecure headers, and input validation failures. Running DAST in staging or production-like environments validates deployed behavior, helping you test and secure the runtime surface that users and attackers interact with.</p><h3>Fuzz testing tools</h3><p>Fuzz testing tools send malformed or unexpected inputs to detect crashes, memory errors, and input validation flaws. They work well for parsers, file upload handlers, and complex input logic where hidden bugs often hide. This approach reveals subtle, high-impact defects that other tools miss.</p><h3>Source code analysis tools</h3><p>Beyond basic SAST, specialized source analyzers inspect dependencies, license issues, and supply chain risks. Tracking vulnerable packages across projects reduces exposure from third-party code and speeds up dependency updates.</p><h3>Configuration auditing tools</h3><p>Configuration auditors compare systems and apps against security benchmarks such as CIS or your internal standards. They find insecure defaults, excessive privileges, and drift from hardened baselines. Ultimately, they help you enforce consistent, auditable security across your environments.</p><h3>Cloud-based vulnerability management platforms</h3><p>Cloud-native scanners and container scanners check IAM rules, misconfigured buckets, insecure container images, and risky runtime policies. Running these with cloud posture management helps catch misconfigurations early in the software development lifecycle (SDLC), protecting fast-moving cloud estates and container pipelines.</p><h2>9 Vulnerability testing best practices</h2><p>Vulnerability testing can be difficult to implement without a structured plan. Follow these 9 testing best practices to get started.</p><h3>1. Make a solid plan</h3><p>Define the scope, objectives, systems, and tools before you start. A well-documented plan keeps teams aligned, clarifies ownership, and ensures the testing process covers all critical areas.</p><h3>2. Test regularly</h3><p>Schedule scans and assessments on a recurring basis. Frequent testing helps you stay ahead of new vulnerabilities and ensures configuration changes or new deployments don’t introduce unnoticed risk.</p><h3>3. Understand your digital landscape</h3><p>Know what assets, applications, and dependencies exist across your environment. A complete inventory helps you test where it matters most.</p><h3>4. Use a variety of methods and tools</h3><p>No single tool covers everything. As such, you should combine automated scanners, manual penetration tests, and code analysis to catch both common and complex software vulnerabilities.</p><h3>5. Establish a robust patch management process</h3><p>Pair testing with timely patching. Monitor for new patches, test them for compatibility, and roll them out efficiently. The faster you fix known vulnerabilities, the less likely attackers are to exploit them.</p><h3>6. Continually adapt</h3><p>The threat landscape is changing faster than ever, especially as more threat actors use AI. Keep testing practices up to date, review documentation, and refine your process as new risks, tools, and frameworks emerge.</p><h3>7. Keep up on the latest threats</h3><p>Track new vulnerabilities, exploit trends, and attack techniques from reputable security advisories and threat intel sources to keep testing relevant and proactive.</p><h3>8. Test in a similar production environment</h3><p>Mirror your live setup during testing so results reflect real-world conditions. Similar environments reveal weaknesses that may not appear in isolated lab tests.</p><h3>9. Keep tools up to date</h3><p>Update scanners, signatures, and frameworks regularly to ensure they detect the newest vulnerabilities accurately and efficiently.</p><h2>Vulnerability testing with Kiuwan</h2><p><br>If you’re looking for a comprehensive platform for vulnerability scanning and secure code analysis across over 30 programming languages, consider Kiuwan. It delivers deep analysis, actionable insights, and detailed remediation guidance that help teams fix issues faster and strengthen security from within the SDLC.</p><p>Try a <a data-mce-href="https://www.kiuwan.com/request-a-trial/?utm_source=partners_website&amp;utm_medium=partners&amp;utm_campaign=dube&amp;utm_term=&amp;utm_content=free_trial" href="https://www.kiuwan.com/request-a-trial/?utm_source=partners_website&amp;utm_medium=partners&amp;utm_campaign=dube&amp;utm_term=&amp;utm_content=free_trial" target="_blank" rel="noopener">free trial today</a> to see how Kiuwan can simplify your vulnerability testing program.</p>

The Complete Guide to Vulnerability Testing

AI Test Case Generation: Build Better Tests with TestRail

AI vs Traditional Test Design: Comparing QA Approaches

<p>Static Application Security Testing (SAST) has become a foundational practice in modern software development. Most teams today can detect vulnerabilities early—but many still struggle with the harder problem: fixing them quickly and at scale.</p><p>Security backlogs grow, developers get overwhelmed by alerts, and remediation slows down release cycles. The real challenge is not identifying issues, but turning findings into fast, high-quality fixes without disrupting delivery.</p><p>Based on what we are seeing across development organizations, the most effective remediation strategies share a common theme: focus on efficiency, prioritization, and developer-friendly guidance.</p><p>Let’s look at how this works in practice using examples from the <a data-mce-href="https://owasp.org/www-project-top-ten/" href="https://owasp.org/www-project-top-ten/" target="_blank" rel="noopener">OWASP Top 10.</a></p><h2>Start with Risk-Based Prioritization (Not Raw Volume)</h2><p>One of the biggest mistakes teams make after running a SAST scan is trying to fix everything at once. This rarely works.</p><p>The most efficient teams will:</p><ul><li>Prioritize high-risk, exploitable issues<br></li><li>Focus first on internet-facing or business-critical applications<br></li><li>Align remediation with OWASP Top 10 categories, which map directly to real-world attack patterns</li></ul><p>For example, issues related to Injection or Broken Access Control should typically outrank lower-impact findings such as informational issues or theoretical risks.</p><p>By reducing noise and focusing on what actually matters, developers can move faster and stay motivated.</p><h2>Injection: Fix Once, Fix Everywhere</h2><p>Injection vulnerabilities, such as SQL injection or command injection, are among the most common findings in SAST tools, and also among the easiest to remediate systematically.</p><h3>Inefficient approach:</h3><p>Developers manually sanitize inputs in dozens of places, often inconsistently</p><h3>Efficient approach:</h3><ul><li>Replace dynamic query construction with parameterized queries or prepared statements</li><li>Centralize database access through secure data access layers<br></li><li>Use SAST findings to identify recurring patterns, then refactor them in batches<br><strong>The key insight:</strong> Injection fixes scale extremely well. One architectural improvement can eliminate hundreds of findings across the codebase. This is where SAST tools provide real leverage, by highlighting patterns, not just individual lines of code.</li></ul><h2>Broken Access Control (OWASP A01): Shift Left into Design</h2><p>Broken Access Control is now the #1 OWASP risk, and SAST tools frequently uncover:</p><ul><li>Missing authorization checks<br></li><li>Insecure direct object references<br></li><li>Role checks are implemented inconsistently</li></ul><h3>Inefficient approach:</h3><p>Adding ad-hoc permission checks deep in business logic<br></p><h3>Efficient approach:</h3><ul><li>Move authorization logic into centralized middleware or frameworks<br></li><li>Standardize role and permission models<br></li><li>Treat access control findings as design flaws, not isolated bugs<br></li></ul><p>Instead of fixing one endpoint at a time, high-performing teams fix the model itself, eliminating entire classes of vulnerabilities in one iteration. SAST findings are most powerful here when they’re used to drive architectural improvements, not just tactical fixes.</p><h2>Security Misconfiguration: Automate the Fixes</h2><p>Security misconfigurations (hardcoded secrets, insecure defaults, debug flags left enabled) are another area where speed matters.</p><p>The fastest remediation strategies rely on:</p><ul><li>Configuration-as-code<br></li><li>Secure default templates<br></li><li>CI/CD policies that prevent insecure settings from being merged<br></li></ul><p>Rather than relying on developers to remember best practices, teams bake security into pipelines and environments.</p><p>SAST tools play a critical role by:</p><ul><li>Identifying insecure patterns early<br></li><li>Enforcing guardrails before code reaches production</li></ul><p>Automation turns recurring fixes into non-events.</p><h2>The Real Accelerator: Developer-Centric Remediation</h2><p><br>Across all OWASP Top 10 categories, one pattern consistently emerges: Teams fix vulnerabilities faster when developers understand exactly what to do and why.</p><p>The most effective remediation workflows include:</p><ul><li>Clear explanations of the vulnerability<br>Concrete, language-specific fix guidance<br>Integration directly into IDEs and CI pipelines<br>Metrics that track time-to-remediate, not just the number of findings</li></ul><p>Security becomes part of daily development, not just a separate, last-minute gate.</p><h2>Final Thought: Detection Is Table Stakes and Remediation Is the Differentiator</h2><p>SAST tools are no longer judged solely on how many vulnerabilities they find. They’re judged on how effectively they help teams fix issues and move forward.</p><p>By focusing on:</p><ul><li>Risk-based prioritization<br></li><li>Architectural improvements over tactical patches<br></li><li>Automation and developer enablement</li></ul><p>Organizations can reduce remediation time without slowing delivery down. In modern AppSec, speed and security are not opposites. With the right approach, they reinforce each other.</p><p><a data-mce-href="https://www.kiuwan.com/request-a-trial/?utm_source=partners_website&amp;utm_medium=partners&amp;utm_campaign=dube&amp;utm_term=&amp;utm_content=free_trial" href="https://www.kiuwan.com/request-a-trial/?utm_source=partners_website&amp;utm_medium=partners&amp;utm_campaign=dube&amp;utm_term=&amp;utm_content=free_trial" target="_blank" rel="noopener">Start a Kiuwan free trial</a>.</p>

From Findings to Fixes: Best Practices to Remediate Vulnerabilities Identified by SAST

<p>Risk-based prioritization is the practice of focusing vulnerability remediation on findings that pose genuine, exploitable risk rather than simply working through scan results in CVSS order.&nbsp;</p><p>For AppSec teams, it’s the difference between a backlog that grows faster than it shrinks and a focused queue of 12 to 20 findings that actually get fixed.</p><p>Enterprise application security scans can generate 8,000+ findings per cycle, yet only 2–5% of vulnerabilities are ever exploited in the wild.&nbsp;</p><p>This guide covers why CVSS-based triage can’t bridge that gap, and what a risk-based approach looks like in practice.</p><h2>TL;DR</h2><ul><li>Enterprise scans generate 8,000+ findings per cycle, yet roughly 3% account for 97% of actual risk.<br></li><li>CVSS scores measure theoretical severity in a vacuum, not whether a vulnerability is reachable or actively exploited.<br></li><li>Risk-based prioritization combines four inputs: asset criticality, reachability analysis, exploit availability, and compensating controls.<br></li><li>The CISA KEV catalog and EPSS provide evidence-based filters that separate active threats from theoretical ones.<br></li><li>Kiuwan Code Security and Kiuwan Insights deliver combined SAST and SCA with prioritized action plans and code-level remediation guidance.</li></ul><h2><br>What is risk-based prioritization in AppSec?</h2><p>In AppSec, risk-based prioritization is a triage methodology that ranks vulnerability findings by their genuine exploitability in your environment rather than by the theoretical severity score assigned at disclosure. The discipline is worth separating from the broader GRC concept of the same name that dominates most search results.&nbsp;</p><p>In GRC, risk prioritization is a governance exercise that involves scoring business risks against likelihood and impact to allocate budget.&nbsp;</p><p>In AppSec, it’s a technical triage discipline that applies contextual intelligence to vulnerability scan output to identify the findings that are genuinely exploitable in your specific environment.</p><p>The contrast with traditional triage is stark. A CVSS-based approach looks like this:&nbsp;</p><ul><li>A scan returns 1,847 findings rated critical or high.<br></li><li>The security team works through them in order of severity.<br></li><li>Six months later, the backlog has grown because new code ships new findings faster than the team can close old ones.</li></ul><p><br>A risk-based approach applies reachability filtering, exploits data, and asset context before findings reach the remediation queue. It effectively reduces thousands of critical findings to 12 to 20 that are genuinely exploitable and fixable in two to three weeks.</p><p>Roughly 3% of vulnerabilities account for 97% of actual risk. Risk-based prioritization is how you find those 3%.</p><h2>Why CVSS-based triage fails</h2><p>CVSS base scores are useful for communicating technical severity, but they are not a complete prioritization model on their own. Base scores reflect the intrinsic characteristics of a vulnerability, while real remediation urgency also depends on exploit activity, asset criticality, reachability, and compensating controls.</p><p>A critical CVSS score for a library that’s never called with attacker-controlled input represents a very different risk than a medium score for a component sitting directly in an exposed API endpoint.&nbsp;</p><p>CVSS can’t distinguish between them.</p><p>The practical consequence is a prioritization model that optimizes for the wrong thing. Teams allocate remediation capacity to high-scoring theoretical vulnerabilities, while genuinely exploitable findings (which may score lower because their attack complexity is rated conservatively) wait in the queue.&nbsp;</p><p>For risk-based vulnerability management to work, CVSS needs to be an input, not the decision.</p><h2>The 4 components of risk-based prioritization</h2><p>Effective risk-based prioritization combines four inputs that CVSS alone can’t provide. Here’s what each one contributes:</p><table style="border-collapse: collapse; width: 100.002%;" border="1" data-mce-style="border-collapse: collapse; width: 100.002%;"><tbody><tr><td style="width: 33.3316%;" data-mce-style="width: 33.3316%;">Component</td><td style="width: 33.3316%;" data-mce-style="width: 33.3316%;">The question it answers</td><td style="width: 33.3352%;" data-mce-style="width: 33.3352%;">Why it matters</td></tr><tr><td style="width: 33.3316%;" data-mce-style="width: 33.3316%;">Asset criticality</td><td style="width: 33.3316%;" data-mce-style="width: 33.3316%;">How damaging would exploitation be?</td><td style="width: 33.3352%;" data-mce-style="width: 33.3352%;">Weighs findings based on data sensitivity, external exposure, and business impact. Not all vulnerabilities in a payment system and an internal dev tool carry the same risk.</td></tr><tr><td style="width: 33.3316%;" data-mce-style="width: 33.3316%;">Reachability analysis</td><td style="width: 33.3316%;" data-mce-style="width: 33.3316%;">Can an attacker actually trigger this?</td><td style="width: 33.3352%;" data-mce-style="width: 33.3352%;">Filters out vulnerabilities in code that’s never called by external input. The single most powerful noise reduction step in the process.</td></tr><tr><td style="width: 33.3316%;" data-mce-style="width: 33.3316%;">Exploit availability</td><td style="width: 33.3316%;" data-mce-style="width: 33.3316%;">Is this being exploited in the wild?</td><td style="width: 33.3352%;" data-mce-style="width: 33.3352%;">The CISA KEV catalog confirms active exploitation; EPSS adds probability scoring for the next 30 days.</td></tr><tr><td style="width: 33.3316%;" data-mce-style="width: 33.3316%;">Compensating controls</td><td style="width: 33.3316%;" data-mce-style="width: 33.3316%;">Is the risk already partially mitigated?</td><td style="width: 33.3352%;" data-mce-style="width: 33.3352%;">A vulnerability behind a WAF or in a network segment with no external access carries lower priority than the same finding without those controls</td></tr></tbody></table><p>Two evidence-based data sources and one decision framework help anchor the exploit availability dimension: CISA KEV, EPSS, and SSVC.</p><p>The <a data-mce-href="https://www.cisa.gov/known-exploited-vulnerabilities-catalog" href="https://www.cisa.gov/known-exploited-vulnerabilities-catalog" target="_blank" rel="noopener">CISA Known Exploited Vulnerabilities catalog</a> lists CVEs confirmed to be exploited in the wild and includes required remediation due dates for Federal Civilian Executive Branch agencies. The <a data-mce-href="https://www.first.org/epss/" href="https://www.first.org/epss/" target="_blank" rel="noopener">Exploit Prediction Scoring System</a> (EPSS) is a machine-learning model maintained by FIRST that predicts the probability that a vulnerability will be exploited within the next 30 days, with a score of 0 to 1. <a data-mce-href="https://www.cisa.gov/stakeholder-specific-vulnerability-categorization-ssvc" href="https://www.cisa.gov/stakeholder-specific-vulnerability-categorization-ssvc" target="_blank" rel="noopener">SSVC (Stakeholder-Specific Vulnerability Categorization)</a> is a CISA-adopted decision tree that converts those signals into action-oriented outcomes (Track, Track*, Attend, Act) based on exploitation status, exposure, and mission impact. KEV signals what is being exploited now, EPSS forecasts what is likely to be exploited soon, and SSVC turns both into a remediation tier.</p><p>Together, these four inputs produce a contextual risk score that reflects actual exploitability in your environment.&nbsp;</p><p>Vulnerability testing that incorporates all four produces results teams can act on, rather than triage lists that require another triage step.</p><h2>Implementing risk-based prioritization in practice</h2><p>Shifting from CVSS-based to risk-based prioritization requires changes to tooling, workflow, and how findings are reported. These are the steps that make it operational.</p><h3>1. Integrate contextual risk scoring at detection via CI/CD</h3><p>Risk context should be applied at the point where findings are generated, not in a downstream manual triage step. That means integrating SAST and SCA scanning directly into your CI/CD pipeline (e.g., by using Kiuwan scans with CI/CD tools such as Jenkins, GitHub Actions, GitLab CI, or Azure DevOps), so that every build produces a prioritized list of findings rather than a raw vulnerability dump.&nbsp;</p><p>Shift-left security that combines SAST findings with asset metadata, reachability data, and CVE enrichment at scan time produces output developers can act on immediately, without a separate security team review, translating raw findings into tasks.</p><h3>2. Apply reachability filtering before building the remediation queue</h3><p>Reachability analysis should run before findings reach the queue.&nbsp;</p><p>This is the step where 8,000 scan results become 12 to 20 genuinely exploitable issues, the reduction that makes risk-based prioritization worth the investment in tooling and process change.</p><h3>3. Build risk-tiered remediation SLAs</h3><p>Once findings are risk-ranked, SLAs should reflect actual exploitability rather than raw severity:</p><ul><li>Tier 1: Confirmed active exploitation (KEV) or high EPSS scores in critical assets should be remediated within 24–72 hours.<br></li><li>Tier 2: Available exploit code or high reachability in important assets can be remediated within two weeks.<br></li><li>Tier 3: Theoretical risk with low reachability or existing compensating controls can be remediated within a regular sprint cycle.</li></ul><p><a data-mce-href="https://www.cisa.gov/stakeholder-specific-vulnerability-categorization-ssvc" href="https://www.cisa.gov/stakeholder-specific-vulnerability-categorization-ssvc" target="_blank" rel="noopener">SSVC (Stakeholder-Specific Vulnerability Categorization) </a>provides a structured framework for building these tiers aligned with how defenders (rather than vendors) think about risk.</p><h3>4. Report in business terms, not CVE counts</h3><p>Stakeholders outside the security team don’t need to know how many critical CVEs are open. They need to know which business risks are unmitigated and the remediation timeline.&nbsp;</p><p>Translating findings into business language (e.g., “three findings in the payment processing stack have confirmed exploits and will be patched by Friday”) is what makes vulnerability remediation programs legible to leadership and easier to incorporate into release planning.</p><h2>Compliance frameworks that require risk-based vulnerability management</h2><p>Risk-based prioritization is no longer optional for regulated AppSec programs. Several major compliance frameworks now require or strongly expect a risk-based methodology, with severity scores alone failing to satisfy the controls.</p><p>PCI DSS 4.0 Requirement 6.3.1 requires organizations to identify and manage security vulnerabilities, assign risk rankings in accordance with industry best practices, and consider potential impacts. Asset criticality and application context are practical ways to support that risk ranking.</p><p>SOC 2 Trust Services Criterion CC7.1 expects evidence that vulnerability prioritization reflects risk to the organization, not raw CVE counts. NIST SP 800-53 (Rev 5) controls RA-5 and SI-2 reference exploit information and asset categorization as inputs to remediation timelines, the foundation of any FedRAMP authorization.</p><p>HIPAA Security Rule 164.308(a)(1)(ii)(A) requires covered entities to conduct risk analysis, while 164.308(a)(1)(ii)(B) requires risk management measures to reduce risks and vulnerabilities to a reasonable and appropriate level.</p><p>AppSec teams in regulated industries have to produce audit-ready evidence at both ends of the process: documented inputs (CVSS, EPSS, KEV, asset criticality, compensating controls) and documented outputs (tier, SLA, remediation evidence). Risk-based prioritization is increasingly the audit standard, not just the operational one.</p><h2>Where risk-based prioritization programs break down</h2><p>The methodology only works when the inputs and the process hold up. These are the failures most likely to drag a program back to CVSS-based triage despite the new tooling.</p><ul><li>CVSS plus filters dressed up as risk-based. Bolting a KEV check or an EPSS threshold onto CVSS-ranked queues is not risk-based prioritization. Real risk-based scoring changes the inputs that produce the queue, not just the filters applied after.<br></li><li>Incomplete asset inventory. Reachability analysis and asset criticality scoring break down when the inventory is wrong. Containers, serverless functions, and ephemeral workloads frequently get missed, leaving gaps in the prioritization logic that show up as quiet findings on assets nobody is tracking.<br></li><li>Static prioritization in dynamic environments. A vulnerability scored low yesterday can become high-risk overnight if exploit code drops, the asset becomes externally reachable, or a compensating control is removed. Prioritization that runs once per scan cycle misses these shifts.<br></li><li>Compensating controls were omitted from the model. Teams often score asset criticality and exploitability but leave existing mitigations out, producing risk scores that overstate exposure and waste remediation cycles on finding that the WAF or network segmentation already neutralizes.<br></li><li>No path from finding to fixing. A perfectly prioritized queue accomplishes nothing if findings are not routed to the developer who owns the code with specific remediation guidance. Without ownership and actionable fix instructions, prioritization just produces a better-organized backlog.</li></ul><p>The common thread is process, not analysis. The teams that get this right invest in continuous asset inventory, scoring at detection rather than triage, and developer-routed remediation, the three operational changes that keep risk-based prioritization from collapsing back into severity-based patching.</p><h2>How Kiuwan supports risk-based prioritization</h2><p>Most vulnerability scanners produce findings.&nbsp;</p><p>Kiuwan Code Security and Kiuwan Insights help teams detect, prioritize, and remediate code-level and open-source component risks with actionable guidance, CI/CD and IDE workflow support, and compliance mappings to widely used standards.</p><p>For AppSec teams managing best practices for vulnerability remediation across large codebases and fast release cycles, that combination of detection, prioritization, and guidance is what makes risk-based prioritization operational rather than aspirational:</p><ul><li>Combined SAST and SCA that surfaces both code-level vulnerabilities and open-source component risk in a single prioritized output.<br></li><li>Prioritized action plans that rank findings by exploitability and business impact rather than raw CVSS score.<br></li><li>Code-level remediation guidance so developers receive specific fix recommendations alongside findings, with no separate triage step required.<br></li><li>Open-source component visibility through Kiuwan Insights, including CVE monitoring, license risk, and transitive dependency analysis.<br></li><li>CI/CD integration for Jenkins, GitHub, GitLab, and Azure DevOps with contextual risk scoring applied at detection, not downstream.<br></li><li>IDE integration that surfaces prioritized findings in the developer’s workflow before code reaches the pipeline.<br></li><li>Static application security testing with compliance mapping to OWASP, CWE, and PCI-DSS is built into every scan.<br></li></ul><p>Risk-based prioritization works when the tooling automatically applies context, not when security teams manually apply it to raw scan output.&nbsp;</p><p><a data-mce-href="https://www.kiuwan.com/request-a-trial/?utm_source=partners_website&amp;utm_medium=partners&amp;utm_campaign=dube&amp;utm_term=&amp;utm_content=free_trial" href="https://www.kiuwan.com/request-a-trial/?utm_source=partners_website&amp;utm_medium=partners&amp;utm_campaign=dube&amp;utm_term=&amp;utm_content=free_trial" target="_blank" rel="noopener" data-mce-selected="inline-boundary">Start a Kiuwan free trial</a> to see how combined SAST and SCA with prioritized action plans fit your remediation workflow.</p>

Risk-Based Prioritization for AppSec Teams

Dube Insights

Distributor of quality & test management, automated testing and security solutions.

Poppins

IBM Plex Mono

IBM Plex Sans

Roboto