Building a Vulnerability Disclosure and Responsible Disclosure Program for SaaS Companies

A security engineer at a growth-stage SaaS company opens a DDQ from a prospective enterprise customer and finds four pages on vulnerability management where there used to be one checkbox. That shift is the whole story: enterprise due diligence questionnaires in 2026 ask about CVSS scoring policies, patch cadence SLAs, CVE tracking processes, and disclosure protocols by name, not as a single yes-or-no line item. A deal that used to clear procurement in a week now stalls on a document most engineering teams never thought to write.

The breaches that caused this are familiar names: MOVEit, Okta, XZ Utils. Each one taught enterprise security teams the same lesson, that a vendor's unpatched vulnerability becomes the buyer's incident, and the DDQ hardening now underway is a direct response to that lesson. Buyers aren't being paranoid: they're pricing in a risk they've already paid for once.

Three separate compliance regimes now back this up with the force of regulation or, in one case, broad industry convention. DORA's Article 9, NIS2's Article 21, and ISO 27001:2022's control A.8.8 (a voluntary standard, not a binding mandate) all require documented vulnerability programs with measurable service-level agreements. A buyer who has to answer for their own compliance under DORA or NIS2 has no choice but to demand the same proof from every vendor touching their systems. That demand rolls downhill, and it lands on companies far smaller than the regulations were written for.

Enterprise security reviewers now treat a formal vulnerability disclosure program as one of five specific things they check in vendor due diligence, alongside CVSS scoring practices, CVE tracking, patch cadence, and web application scanning. Leave it off, and the gap doesn't read as neutral. It reads as a company that hasn't thought about security the way its buyers now have to. If it's built correctly, it answers the questions before they're asked.

The EU Cyber Resilience Act's June 2026 deadline for SaaS companies

Most SaaS teams have already misjudged how much of the Cyber Resilience Act applies to them. Articles 13 and 14 made the vulnerability reporting obligations binding on June 11, 2026, and the broader product-safety requirements don't take effect until December 2027.

Scope hinges on one technical question: does any part of the software get distributed to and run on a user's device or infrastructure, rather than staying entirely server-side. If a SaaS product is genuinely pure server-side, with nothing distributed, it likely sits outside CRA scope. But that's a narrower category than most teams assume. Any product that ships a desktop client, a mobile app, a browser extension, a CI/CD plugin, an open-source SDK, or a Docker image pushed to a public registry is almost certainly in scope as of June 2026. The European Commission's CRA FAQ states that a SaaS platform that bundles a browser extension, a mobile app, or a CI/CD plugin falls under the regulation. Companies that believe they fall outside the CRA should write that reasoning down and keep it on file rather than simply assuming the regulation doesn't apply.

Article 14 runs on a two-step reporting clock managed through ENISA. The first step is an early warning, and it's due within 24 hours of a company becoming aware that a vulnerability is being actively exploited. That initial report needs to give the product name and version, a vulnerability identifier, evidence of how it's being exploited, and an initial impact assessment. Root cause analysis isn't required at this stage. "Actively exploited" means there's evidence of exploitation already happening in the wild, a narrower trigger than the significant-incident threshold NIS2 uses, but one that moves on a much faster clock once it's tripped.

The obligations extend to companies that don't build software themselves. Distributors and importers, meaning companies that resell, white-label, or bundle someone else's components into their own product, now have to verify that the manufacturers of those embedded components run compliant vulnerability handling processes. Supplier security questionnaires used to be a courtesy for cautious customers, but as of June 2026 the CRA makes them a legal due-diligence requirement.

The structural difference between a VDP and a bug bounty program

A vulnerability disclosure program and a bug bounty program solve different problems, and treating them as interchangeable produces programs that satisfy neither researchers nor auditors. A VDP is a policy and a process. It tells a security researcher how to report what they find, what they're allowed to test and what they're not, what response the company commits to, and what legal protection they get in return. It does not pay out money.

A bug bounty program sits on top of that same infrastructure and adds a financial incentive: reward tiers, expanded scope, a payout mechanism for valid findings. A bounty program without a VDP underneath it doesn't really exist, because the scope rules, the reporting channel, and the safe harbor language all have to exist first.

SAS's 2026 policy states explicitly: "SAS does not currently operate a Bug Bounty programme and does not offer financial rewards, EuroBonus points, gifts, compensation, or other incentives in exchange for vulnerability reports". The policy goes further, stating that it is "not the terms of a Bug Bounty programme". That's not a hedge or an oversight. SAS draws this line in public, on purpose, so researchers know what they're submitting reports in exchange for, and so SAS's own legal and financial obligations stay bounded.

For a growth-stage SaaS company, a VDP is the correct starting point. It builds the documented channel and legal framework that both researchers and auditors need to see, and it does that without the operational weight of managing bounty payments, reward disputes, and payout fraud that a bug bounty program brings with it. When enterprise buyers review vendor security, they want to know whether a structured intake channel exists and whether the company has written down how it responds to reports. A bug bounty program is one signal of security maturity, but it's not what DDQs are checking for. A VDP is what satisfies the requirement.

The seven components every audit-ready VDP must contain

A VDP that holds up under both researcher scrutiny and enterprise audit is a set of interlocking parts, each doing a distinct job, and skipping any one of them leaves a gap that an auditor or a DDQ reviewer will find.

Every audit-ready VDP opens by naming what's in bounds and what isn't, starting with scope definition. SAS limits its scope to assets that SAS owns, directly manages, and makes publicly accessible, and it names specific domains and apps while explicitly excluding third-party providers, supplier platforms, airport systems, alliance partner environments, and any externally hosted service unless SAS has authorized it in writing. Infotech's program lists specific in-scope wildcard domains and adds a simple rule: if a researcher can't tell whether an asset belongs to Infotech or to a third party, they should assume it's out of scope. A SaaS company building its own VDP should name production domains, API endpoints, mobile apps, and any distributed components, and explicitly rule out the third-party tools it relies on, like payment processors, analytics vendors, and support platforms. Scope protects the company from legal exposure on systems it doesn't fully control, and it's one of the first things both researchers and auditors check for.

Authorized research guidelines are part of a complete VDP, which tells researchers what they can do: take only the steps needed to prove a vulnerability exists, stop immediately if they hit personal data or live credentials, and report right away if sensitive data gets exposed; then it spells out what's off-limits. Both SAS and Infotech publish explicit prohibition lists: no credential attacks or brute forcing, no denial-of-service or performance testing, no lateral movement into other systems, no posting findings to public repositories or social media, no privilege escalation beyond what's needed to demonstrate the bug. This list functions as the legal boundary of the whole program. Safe harbor protection is conditioned on staying inside it.

Vulnerability classes in scope, and explicitly out of scope. Picus names the vulnerability classes it wants reported: cross-site scripting, CSRF, authentication and authorization flaws, SSRF, SSTI, SQL injection, XXE, remote code execution, and local or remote file inclusion. Picus also excludes a specific list from consideration: the autocomplete attribute on web forms, missing cookie flags on non-sensitive cookies, missing security headers that don't lead to an actual exploitable issue, UI and spelling bugs, unvalidated automated scanner output, and banner or version disclosure with no correlated vulnerability behind it. Infotech's exclusion list covers DoS and DDoS, attacks that depend on a man-in-the-middle position, clickjacking with no real-world impact, content spoofing without a working attack vector, bare version disclosure without proof of exploitability, and OAuth secret leaks from mobile apps that require a rooted device, unless a researcher can clearly demonstrate the exploit works. These exclusion lists exist for a practical reason: without them, a triage team drowns in low-value noise, automated scan output, missing-header reports, SPF misconfigurations, none of which represent real risk. A SaaS company writing its own list should name IDOR and BOLA explicitly, because broken object-level authorization occurs constantly in multi-tenant architectures, and it should decide deliberately whether business-logic flaws belong in scope, because they're real risks but harder to define cleanly.

Submission channel and report quality requirements. A dedicated email address, ideally with a published PGP key for encrypted reports, is the standard way researchers submit findings. SAS uses security@sas.se with a public PGP key, and Infotech uses disclosure@infotechinc.com. Across programs, the reports that get taken seriously share a shape: the vulnerability type, the affected domain or endpoint, clear step-by-step reproduction instructions, proof-of-concept material like screenshots or request and response examples, a sense of business impact, and ideally a suggested fix. Picus says reports with working proof-of-concept code get triaged faster, but if a report is just crash dumps or raw automated-tool output, it sits lower in the queue. Infotech asks researchers to include the IP address they tested from, a small but useful detail that lets the security team tell real researcher traffic apart from an actual attacker. And if a researcher happens to access personal data during testing, SAS's policy treats that as a potential data breach that needs immediate escalation, tied directly to GDPR obligations.

Triage and response service-level agreements. This is the component that turns a VDP from a policy statement into an operational commitment. Acknowledgment timelines vary across real programs: SAS aims to acknowledge a report within seven business days, Infotech commits to confirming validity within seven days, and Picus doesn't publish a specific acknowledgment window at all. After acknowledgment, the real work starts: confirming the issue reproduces and sits in scope, scoring severity with CVSS, weighing exploitability and operational impact, deciding on a remediation path, and keeping the reporter informed where appropriate. Resolution timelines move depending on severity, operational complexity, regulatory considerations, third-party dependencies, and in SAS's case, aviation-specific operational constraints. The practical lesson for a SaaS company is this: don't promise a single fixed resolution window across every severity level, because that's a commitment most teams can't keep. It's to be honest in the policy about what actually affects timing. Internal response SLAs should map to CVSS severity bands, and those bands should match whatever answers the company is already giving in its DDQs, with critical findings routed through a dedicated escalation path separate from the standard triage queue.

Safe harbor and a non-retaliation commitment. Infotech's safe harbor applies only under specific conditions: the researcher stayed within the defined scope and testing guidelines, didn't access personal data or confidential information, and didn't degrade production systems. It explicitly excludes residents of sanctioned countries. Safe harbor is the line that separates a vulnerability disclosure program from a cease-and-desist culture. Without it, researchers acting in good faith just stop reporting, and vulnerabilities stay hidden until someone with worse intentions finds them first. The commitment needs to be written clearly, placed prominently, reviewed by legal counsel, and specific about both what it covers and what falls outside it. A single reassuring sentence buried in a footer isn't a safe harbor policy.

Disclosure coordination and a public timeline. The last piece closes the loop: how the company and the researcher coordinate on when and how a confirmed vulnerability becomes public, and what timeline governs that process once a fix is ready. It protects both the researcher's credit for the find and the company's ability to patch before details go public, turning a one-off report into a repeatable, trustworthy program that researchers want to use again.