Safe harbor for researchers, homework for system owners

The week

On May 19, 2022, the Department of Justice announced a revised policy for charging cases under the Computer Fraud and Abuse Act. Federal prosecutors were directed not to charge good-faith security research. The policy defined it as accessing a computer solely to test, investigate or correct a security flaw, in a manner designed to avoid harm, with the information used primarily to promote security. The policy also said that breaches of contractual terms, such as a website’s terms of service, should not on their own be charged. It followed the Supreme Court’s 2021 Van Buren decision, which narrowed the meaning of exceeding authorized access. It was a statement of prosecutorial policy, not a change to the statute, and it did not affect state computer crime laws or civil claims.

Earlier in this series we looked at what Van Buren meant for insiders who misuse access they legitimately hold. The DOJ policy dealt with the opposite case: outsiders who probe a system to find weaknesses and report them. The researcher community read it as a reduction in legal risk. For state and local agencies, the more practical consequence was volume. When researchers feel safer, more of them report, and more reports arrive at organizations that have never received one.

Federal civilian agencies were already set up for this. CISA’s Binding Operational Directive 20-01, issued in 2020, required them to publish vulnerability disclosure policies for internet-facing systems. Most state agencies, counties, cities, courts and school districts had no such requirement and, often, no published process. When a researcher found a flaw in a permit portal or a court records site, the report went to a general inbox or a social media account. Turning those reports into fixes is an operations problem with three distinct stages: the front door where reports arrive, the route from report to the person who can fix the flaw, and the close of the loop with the researcher and with leadership.

The front door

A front door has a published address and published terms. The address can be a dedicated email alias or a web form. List it on a security page and in a standard security.txt file on public websites, where many researchers look first. The terms say which systems are in scope and which testing methods are off limits, such as denial of service or accessing other people’s data. They also say the agency will not pursue legal action against researchers who follow the policy. Agencies should have counsel review that commitment, since state law and the agency’s authority to make it vary.

The front door needs staff behind it. Someone has to read every report, acknowledge it, and judge whether it is credible. Most reports to a public agency are low quality: automated scanner output, missing security headers, or requests for payment. A few are serious. Distinguishing them takes a security analyst, not a general help desk. For a small agency, that role might be part of a shared service run by the state, a regional consortium or a managed security provider. What matters is that a named person or team owns the inbox and checks it daily.

Federal resources can help. CISA operates a vulnerability disclosure platform for federal agencies, and its published template policy is a reasonable starting point for any public body drafting its own.

The route to the fixer

The weakest link in most disclosure programs is the handoff after a report is validated. Security staff can confirm a flaw. They usually cannot fix it. The fix belongs to an application owner, an infrastructure team or, very often, a vendor.

Public-facing systems in government are heavily vendor-run: payment portals, permitting platforms, court e-filing, library systems, utility billing. A researcher reports to the agency whose name is on the page. If the agency has no contractual way to make the vendor act, it owns the reputational risk without owning the remedy. Contracts and renewals should require vendors to accept forwarded vulnerability reports, acknowledge them within a set time, fix by severity-based deadlines, and tell the agency when a fix is deployed. They should also require the vendor to tell the agency about reports it receives directly that affect the agency’s deployment.

Inside the agency, validated reports should enter the same ticketing and severity process as findings from internal scans and penetration tests, with an owner and a due date. A separate spreadsheet for outside reports tends to become a list of forgotten items. Severity should follow the agency’s existing scale, adjusted for public exposure and the sensitivity of the data involved.

Closing the loop

The last stage has two audiences. The first is the researcher. Researchers who hear nothing tend to follow up, then publish. A short acknowledgment within a few business days, an update when the fix is scheduled, and a note when it is deployed prevent most premature disclosure. Some agencies offer public acknowledgment on a thanks page. Most researchers value a timely, respectful response more than any reward.

The second audience is leadership. A disclosure program produces simple, honest metrics: reports received, share validated, time to acknowledge, time to triage and time to remediate, broken out between agency-run and vendor-run systems. That split usually shows where the bottleneck is. If vendor-run systems take far longer to fix, procurement has a contract problem to solve at the next renewal.

Workforce planning follows from those numbers. An agency that receives a handful of reports a year can absorb them in an existing role. One that runs many public services may need a part-time coordinator, a shared regional service or a contract with a provider. Starting small and measuring is better than either ignoring the inbox or building a large program for a volume that never arrives.

Communications and legal staff belong in the loop as well. Researchers sometimes go public before a fix, and an agency that has agreed in advance how it will respond, and who speaks, avoids a defensive reaction that discourages the next report.

With hindsight

The policy has held; we are not aware of it being withdrawn. Vulnerability disclosure has moved from courtesy to expectation. CISA’s secure-by-design guidance, published with international partners from 2023, called on software makers to publish disclosure policies, which pushed vendors serving government to accept outside reports. The European Union’s Cyber Resilience Act, which entered into force in December 2024, requires manufacturers of products with digital elements to handle vulnerabilities through coordinated disclosure, with reporting obligations from September 2026. A number of states, often through their central IT agencies, have published disclosure policies for state systems, though coverage at the county and city level remains uneven. The weak point has not changed. Agencies that wired outside reports into their normal remediation process, and wrote vendor obligations into contracts, now treat researchers as extra testing capacity. Those that did not still learn about their flaws from public posts.