What is application vulnerability management?
Application vulnerability management is the ongoing process of finding, ranking, fixing, and verifying security flaws in software. Findings come from scanners, penetration tests, bug bounty reports, and dependency alerts. Each severity level usually has a target fix time, such as critical issues within days.
What the buyer is really asking
Cover the whole loop: how vulnerabilities are found, how they are ranked by severity, and how long each severity may stay open. Targets you actually meet are worth more than aggressive ones you miss.
Other ways buyers ask it
Every one of these wants the same answer:
- “How do you manage application vulnerabilities?”
- “What are your remediation timelines by severity?”
- “Do you have a vulnerability disclosure program?”
Evidence to have ready
- A vulnerability management policy with remediation targets
- Tracking records for recent findings
- A security.txt or disclosure page, if published
Sample answers by company stage
The right answer depends on what you actually run today. Each sample below is honest only if its condition is true for you. Swap the bracketed details for your own.
Early startup
Use this if: You fix what your scanners report but have no written policy or formal deadlines yet.
We find application vulnerabilities through dependency scanning with [Dependabot], static analysis with [CodeQL], and reports sent to [[email protected]]. Engineering triages new findings [weekly]. Our working targets are [7] days for critical issues and [30] days for high issues. We track every finding as a ticket in [Linear]. These targets are our current practice and are not yet written into a formal policy.
Scaling
Use this if: You have a written policy with remediation deadlines by severity and can show recent performance against them.
Our vulnerability management policy defines how findings are identified, rated, fixed, and verified. Sources include static analysis, dependency scanning, dynamic scanning, penetration tests, and our vulnerability disclosure program. We rate severity with CVSS and adjust for exploitability and exposure in our environment. Remediation targets are [7] days for critical, [30] days for high, [90] days for medium, and best effort for low. A finding that cannot meet its target needs a documented exception with compensating controls and an expiry date. We review open findings and deadline performance [monthly]. Our security.txt file explains how to report a vulnerability.
Enterprise-ready
Use this if: Deadline performance is measured and reported, the process is audited, and you run a public disclosure or bug bounty program.
We prioritize findings with CVSS, the CISA Known Exploited Vulnerabilities catalog, and EPSS scores. Anything on the CISA list is treated as critical regardless of its base score. Remediation deadlines are [7] days for critical, [30] days for high, and [90] days for medium. Deadline performance is reported to leadership [monthly]. Over the last [12 months] we closed [95%] of critical and high findings within target. Our SOC 2 Type II auditor tests the policy and a sample of closed findings. We publish a disclosure policy with safe harbor language and run a bug bounty through [platform]. Customers are notified of vulnerabilities that affect their data as our contracts require.
How the major questionnaires word it
Each standard questionnaire asks this in its own structure. These are paraphrased summaries, not the licensed question text.
- CAIQ v4 (Cloud Security Alliance)
- The Threat and Vulnerability Management domain has rows for a policy, a remediation schedule, risk-based prioritization, reporting, and metrics. Vulnerabilities in third-party libraries get a row of their own. Application Security has one more row for application vulnerability remediation.
- SIG (Shared Assessments)
- SIG asks for remediation timeframes by severity and whether they are documented. Buyers often compare your numbers with their own internal standard, so modest targets you meet beat aggressive ones you miss.
- VSA (Vendor Security Alliance)
- VSA-style questionnaires ask how you track and fix vulnerabilities and whether outside researchers have a way to report issues to you.
- HECVAT (higher education)
- HECVAT asks whether you have a vulnerability reporting process and what your patching timelines are. Give numbers, not adjectives, in the additional information column.
More evidence reviewers accept
- A deadline performance report for a recent quarter, by severity
- A summary of currently open findings by severity and age
- A sample exception record with its compensating control and expiry date
- Your security.txt file and published disclosure policy
- Verification evidence for a recently closed critical finding
Red flags reviewers look for
- Deadlines you do not meet. Aggressive targets with no metrics read worse than modest targets you can show you hit. Reviewers may ask for your actual numbers.
- No exception process. Some findings cannot be fixed in time. Without a documented exception path, every miss is a silent policy violation.
- No way for outsiders to report. Without a security contact or security.txt file, researchers who find a bug have nowhere to send it. Reviewers check for one.
- Scanner defaults as severity. Taking every scanner rating at face value wastes effort on noise and misses real risk. Say how you adjust for exposure and active exploitation.
- Old critical findings still open. An open critical that is months old contradicts any deadline you state. Close it or document the exception before you send the questionnaire.
- Patching the app but not the platform. Operating system packages, container images, and managed service versions need the same deadlines as your code. A policy that covers only application findings leaves half the attack surface out.
Follow-up questions to expect
How do you decide severity?
Say whether you use the scanner or CVSS score as is or adjust it. Adjusting for whether the vulnerable code is reachable and exposed is normal and worth explaining.
Will you tell us about vulnerabilities that affect us?
Check your contract before answering. Commit to notifying customers of vulnerabilities that were exploited or that exposed their data. Do not promise notice of every finding.
Do you track end-of-life components?
Frameworks, runtimes, and base images stop getting security fixes. Say how you notice an unsupported version and how quickly you move off it.
How many critical findings are open right now?
Some buyers ask for the number. If it is zero, say so with the date. If it is not, give the count with the planned fix dates and any compensating controls.
What counts as fixed?
A merged pull request is not always a fix. Say whether you confirm remediation with a rescan, a retest by the original reporter, or a check that the patched version is actually deployed everywhere. Buyers who have been burned before ask this directly. A finding closed on the ticket but still live in production is the gap they are looking for.
How Tyrvar answers this
Tyrvar treats every wording above as one question. You write the answer once, attach the evidence, and revisit it when your setup changes. Each buyer gets that approved answer no matter how their questionnaire words it. If you have not answered it yet, Tyrvar flags the question for you and does not make something up. Try it on your own questionnaire.