Vulnerability intake

Vulnerability intake is how news of a vulnerability in your software reaches someone who will act on it: reports from researchers and customers through a published disclosure channel, and advisories for the third-party components you ship, matched by monitoring tools.

Your own testing finds what you look for. Researchers, customers and the maintainers of your dependencies find the rest, and they need somewhere to send it. Without a known route, a researcher's report lands in a sales inbox or a public issue tracker, and an advisory for a library you ship sits in a scanner dashboard that nobody owns, while attackers read the same advisory.

Who: A named intake owner or PSIRT rotation, with support forwarding reports and service teams receiving component alerts
When: From the first release onward, and before any new public host, product or open-source repository goes live
How often: Component monitoring on every build and daily; the report queue watched every business day
You end up with: A disclosure policy, a security.txt file per host, one monitored queue, and a tracked record with an owner for every report

Do this

Name an owner and one queue
Pick the person or on-call rotation that owns intake, and route every source into one tracked queue: the disclosure mailbox or form, bug bounty submissions, support tickets and scanner alerts. The FIRST PSIRT Services Framework expects reports to arrive from other parts of the company too, so give support staff a rule to forward anything that looks like a vulnerability report the same day.
Publish a vulnerability disclosure policy
State the scope (domains, apps and products), which testing is and is not allowed, how to report and what details to send, a commitment not to pursue legal action over good-faith research, and when reporters will hear back. CISA BOD 20-01 requires these elements of US federal agencies and makes a usable model; disclose.io publishes public-domain templates. Have counsel review the safe-harbor wording.
Publish security.txt on every public host
Serve /.well-known/security.txt over HTTPS as text/plain, with at least one Contact and exactly one Expires, which RFC 9116 recommends keeping less than a year ahead. Add Policy to link your disclosure policy. The file covers only the host that serves it, so publish one per hostname and check each with security.txt validator. On GitHub, also turn on private vulnerability reporting for public repositories.
Acknowledge and record every report
Reply from a person, not only an auto-responder, with a case ID and the date of the next update. Set targets and publish them: CISA recommends acknowledging within 3 business days, an initial assessment within 7 days and resolution within 90 days. Record the source, receipt time, product and version, and owner, and reproduce with your own test accounts rather than asking the reporter for more real customer data.
Monitor advisories for what you ship
Keep a component inventory per release, such as an SBOM (SBOM and provenance), so advisories match exact versions. Scan lockfiles and built images against databases such as OSV.dev, on every build and on a schedule, with tools such as OSV-Scanner or Dependabot alerts. Subscribe to vendor and distribution advisories, check the CISA KEV catalog daily, and route each new match to the owning team automatically.
Test the route on a schedule
Send a test report through each published channel, for example once a quarter, and time the reply against your target. Fail a scheduled check when a host lacks security.txt or its Expires date is near. Track reports received, valid reports and median time to acknowledge, so an unread mailbox shows up as a number rather than as a surprise.

Done when

Reports and component advisories reach a named owner within days, and a security.txt file on every public host says where to report.

Mark it in the gap check

Common mistakes

A security mailbox that nobody monitors, or that only an auto-responder answers. Reporters cannot tell active work from neglect, and the first you hear of the flaw may be its public disclosure.
Publishing security.txt only on the main domain, or letting Expires pass. RFC 9116 scopes the file to the host that serves it, so api. and app. hosts are left without one.
Claiming scope you cannot authorize, such as a vendor's help desk on your subdomain. Safe harbor binds only you, and researchers may rely on the scope you published.
Monitoring the repository instead of what ships. Lockfile alerts miss the old image still running, while development-only packages flood the queue.
Leaving scanner alerts in a dashboard with no owner. An alert nobody is assigned is not a report anyone handles; route each one to a team queue.

Where vulnerability reports come from

A common intake gap is a source with no route into the queue. List each source and what it needs.

Where vulnerability reports come from: table
Source	Typical channel	What to set up
External researchers	Disclosure form, `security.txt` contact, bug bounty platform	Policy with scope and safe harbor, published response targets
Customers	Support tickets	A forwarding rule and a template that asks for version and impact
Maintainers and vendors of your components	OSV and GitHub advisories, vendor and distribution advisories	A component inventory per release and automated matching
Exploitation reports	CISA KEV feed or update subscription, vendor alerts	A daily check against deployed components
Coordinators	CERT/CC, national CSIRTs	A contact they can find, such as `security.txt`
Internal	Penetration tests, code review, scanners, incident investigations	The same queue and record as external reports

Tools and guides

Tool: security.txt validator
Tool: OSV dependency lookup
Workflow: Respond to a vulnerability
Start with a VDP, then add bug bounties and penetration tests
Publish a vulnerability disclosure policy and security.txt first, add a bug bounty only when you can triage and fix at the pace rewards bring, and buy penetration tests with a written scope, rules of engagement and a retest.
Run coordinated vulnerability disclosure from report to advisory
Make private reporting discoverable, verify reports, coordinate a tested remedy, and give affected users enough information to act.
Set up a PSIRT: services, intake, triage, SLAs and the CNA role
How to structure and run a product security incident response team on the FIRST PSIRT Services Framework: organizational models, intake channels, triage, response targets, a case record and SLA script, becoming a CVE Numbering Authority under the CNA rules 4.2.0, and coordinating with other vendors.

Standards

NIST SSDF 1.1: RV.1 Identify and Confirm Vulnerabilities on an Ongoing Basis
OWASP SAMM 2: Defect ManagementSecure Build

Vulnerability intake

Do this

Name an owner and one queue

Publish a vulnerability disclosure policy

Publish security.txt on every public host

Acknowledge and record every report

Monitor advisories for what you ship

Test the route on a schedule

Done when

Common mistakes

Where vulnerability reports come from

Tools and guides

Standards

Sources

Find your next answer