Managing Web Application Vulnerabilities Alongside Infrastructure Findings

Web application vulnerabilities usually live in your own code or in the components your developers chose, so they're fixed by developers changing code and shipping a release, not by IT installing a vendor patch. To manage them alongside infrastructure findings, keep one view of risk and a shared severity scale, but give application findings their own workflow. Route them into development backlogs, deduplicate across tools, set deadlines that fit release cycles, use a web application firewall only as a temporary stopgap, and retest before you close anything.

This post covers how the two kinds of findings differ, the main testing methods, a common vocabulary, and the workflow that connects them.

How are web application findings different from infrastructure findings?

Most infrastructure vulnerabilities have a known fix from a vendor. Your job is to find affected systems, schedule the update and confirm it installed. Custom application vulnerabilities often have no advisory, no CVE and no published score, because the flaw exists only in your code.

Vulnerable third-party libraries sit between the two. They have CVEs like infrastructure findings, but a developer still has to upgrade the component, test the application and ship a new build.

What are DAST, SAST and SCA?

Each testing method sees a different part of the problem. Most organizations need more than one.

Dynamic application security testing (DAST)

DAST tests a running application from the outside, sending crafted requests and analyzing the responses. It finds issues that show up at runtime, such as injection flaws, cross-site scripting, weak session handling and server misconfiguration. It doesn't need source code.

Its blind spots are the parts of the application it can't reach. Without a working login configuration it may test only the public pages. Active testing can also create or change data, so run it against a staging environment where you can.

Static application security testing (SAST)

SAST analyzes source code or compiled code without running it. It can catch flaws early, before code reaches production, and it points developers to the file and line involved.

The trade-off is noise. SAST tools can report many false positives until they're tuned for your frameworks and coding patterns, and they can't see how the application is configured and deployed.

Software composition analysis (SCA)

SCA inventories the open-source and third-party components your application uses and matches them against known vulnerabilities. It addresses A9:2017 in the OWASP Top 10, "Using Components with Known Vulnerabilities." Findings are usually easy to understand, since each maps to a CVE and a fixed version, though the upgrade itself may take real work.

Manual testing

Automated tools struggle with business logic and access control flaws, such as one user being able to see another user's records by changing an ID in a request. Periodic manual penetration testing covers what scanners miss, especially for your most important applications.

What common vocabulary should you use?

When findings come from four different sources, you need a shared language for reporting and trend analysis. OWASP publishes two free references that work well together.

OWASP Top 10 2017

The OWASP Top 10 is a widely recognized list of the most critical web application security risk categories. The 2017 edition includes:

1. A1 Injection
2. A2 Broken Authentication
3. A3 Sensitive Data Exposure
4. A4 XML External Entities (XXE)
5. A5 Broken Access Control
6. A6 Security Misconfiguration
7. A7 Cross-Site Scripting (XSS)
8. A8 Insecure Deserialization
9. A9 Using Components with Known Vulnerabilities
10. A10 Insufficient Logging & Monitoring

Tag each finding with its Top 10 category. You can then report progress by category, such as open injection findings, across every tool and application. Treat the list as vocabulary, not as a complete standard, because plenty of real vulnerabilities fall outside it.

OWASP ASVS 4.0

The Application Security Verification Standard, version 4.0, was released in March 2019. It works as an actual standard: a list of testable security requirements, organized into 14 chapters from architecture and authentication through to API security and configuration. Requirements map to CWE, and the authentication chapter aligns with NIST SP 800-63.

ASVS defines three verification levels:

• Level 1 for low-assurance applications. It's the only level that can be verified entirely through penetration testing, without access to source code.
• Level 2 for most applications, particularly those that handle sensitive data or significant business transactions.
• Level 3 for the most critical applications.

Assign a target level to each application. Findings then become gaps against a specific requirement, which gives developers a clear definition of "fixed."

How do you route findings to development teams?

The biggest difference from infrastructure work is the destination. A finding in the IT operations ticket queue or a security spreadsheet will sit there, because developers plan their work from their own backlog.

• Maintain an application inventory. Map each application to an owning team, a code repository and a product owner, just as your asset inventory maps servers to system owners.
• Triage before you hand over. Have security confirm findings first, especially from SAST. A backlog full of false positives destroys developer trust quickly.
• Create tickets in the team's own issue tracker. Include the affected URL and parameter or the file and line, the evidence, the CWE and Top 10 category, the severity with a short rationale, and remediation guidance.
• Agree on how security work competes with features. The product owner should commit to deadlines by severity. Otherwise security tickets tend to lose out in sprint planning.
• Build a relationship. A developer in each team who takes an interest in security, often called a security champion, makes this much smoother.

How do you deduplicate findings across tools?

The same flaw often appears several times. A DAST scan reports it by URL, SAST reports it by line of code, and a penetration test report describes it in prose. A single vulnerable template can produce the same cross-site scripting finding on fifty pages.

To keep the backlog honest:

• Normalize findings to a weakness type (CWE), a location and an application.
• Group by root cause. If one shared function causes fifty findings, raise one ticket to fix the function and list the affected pages inside it.
• Group SCA findings by component and version. One library upgrade can close several CVEs at once.
• Keep each tool's own finding ID so you can tell whether a finding in the next scan is the same issue, a fixed issue or a new one.

Aim for a single place where you can see application and infrastructure findings together, even if each flows into a different team's tracker.

How should you set severity and SLAs for application vulnerabilities?

Custom code vulnerabilities don't arrive with a published score, and tool severities vary between products. For consistency with infrastructure findings, score confirmed application vulnerabilities yourself using CVSS v3.1. Then weigh the context CVSS leaves out: whether the application faces the internet, whether exploitation needs a login, and how sensitive the data is.

Use one severity scale across the program, but set deadlines that match how code ships. For example:

Adjust these to your own release cadence, then track deadline compliance by team. Leadership can then compare application and infrastructure performance on the same terms.

When should you use a WAF for virtual patching?

A virtual patch is a web application firewall (WAF) rule that blocks requests exploiting a specific flaw while the code fix is being built. It's useful when a serious finding needs protection now and the fix will take time, or when you're running a third-party application you can't change yourself.

Treat it as a stopgap:

• It doesn't fix the flaw. Attackers may bypass a rule with encoding tricks or alternative request paths.
• It can block legitimate traffic. Run the rule in logging mode first where you can, then switch it to blocking.
• It needs an owner and an expiry date. Record it as an exception linked to the open ticket, and keep the finding open until the code is fixed.

Why is retesting so important?

A merged pull request isn't proof that a vulnerability is gone. Verify each fix using the same technique that found it: rerun the DAST check against the affected URL, rescan the code, or ask the penetration tester to retest. Close the finding only after the retest passes.

Two habits make fixes stick. Ask developers to add an automated test that would catch the flaw if it came back. And when you confirm one instance of a weakness, search the code base for the same pattern elsewhere. Track how often closed findings reopen, since a rising reopen rate usually points to fixes that address symptoms rather than causes.

Frequently asked questions

Should application findings go in the same ticketing system as infrastructure findings?

Not necessarily. Route each finding to the tracker its owners already use, and aggregate the reporting centrally. What matters is one view of risk, not one ticket queue.

Do we need DAST, SAST and SCA all at once?

No. A sensible starting point is DAST on internet-facing applications and SCA across all of them, since both produce findings that are relatively easy to confirm. Add SAST once you have the capacity to tune it and triage its results.

Can a WAF replace fixing the code?

No. A WAF reduces exposure while the fix is built. The vulnerability remains in the code and can resurface if the rule is bypassed, changed or removed.

Next steps

• Build an application inventory with an owning team and repository for each application.
• Tag every finding with a CWE and an OWASP Top 10 2017 category, and set an ASVS target level per application.
• Deliver triaged, deduplicated findings into development backlogs, not operations queues.
• Agree severity-based deadlines that fit your release cadence.
• Use WAF virtual patches only with an owner and an expiry date, and close findings only after a successful retest.