Cam's Cyberspace

Recent Notes

Coordinated Vulnerability Disclosure and Safe Harbor

Properties3
descriptionWhat a safe harbor clause in a disclosure policy is as an instrument, why the operative words are deem that activity authorized, and what the 2022 change to the CFAA charging policy did and did not do.
tagscs, law
aliases

8 min read

“Safe harbor” sounds like a legal status. It is not one. There is no statute that confers it on a researcher, no registry to join, and no certificate. What exists instead is a paragraph that an organization chooses to publish, plus a separate internal instruction that the Department of Justice chose to write. The two operate on completely different machinery, and reading them as one thing is how people end up surprised.

The idea

The load-bearing words in a safe harbor clause are not the promise not to sue. They are the words that grant authorization. Both the criminal computer-access statute and the DMCA security testing exemption turn on whether access was authorized, so a policy that says testing within scope is authorized does not create a defense, it removes an element the prosecution or the plaintiff would otherwise have to prove. The promise not to sue is the softer half. The grant of authorization is the half that reaches into the statute.

The anatomy, taken from a directive that specifies one

Federal civilian agencies have to publish a disclosure policy, and the directive that requires it is unusually explicit about what the document must contain, which makes it the cleanest available specimen of the form.

The directive frames the policy’s purpose in one sentence: “It commits the agency to authorize good faith security research and respond to vulnerability reports, and sets expectations for reporters.” Before publishing anything, “an agency must have the capability to receive unsolicited reports about potential security vulnerabilities,” which is the part organizations most often skip. A policy with no monitored inbox behind it is a document, not a channel.

The required contents read like an interface specification. Which systems are in scope, and “at least one internet-accessible production system or service must be in scope at the time of publication.” The types of testing allowed or not allowed. Where reports go, and what information they should carry: a description of the vulnerability, its location and potential impact, technical information needed to reproduce, any proof of concept code. That list is the reason a disclosure policy and a CVE record tend to want the same fields, and the reason a good report is mostly reproduction steps.

Then the clause everyone is actually looking for: the policy must include “a commitment to not recommend or pursue legal action against anyone for security research activities that the agency concludes represents a good faith effort to follow the policy, and deem that activity authorized.”

Read the two halves separately. The first is a forbearance, a promise about future conduct. The second is a grant. Deeming activity authorized is not a promise at all, it is an act with legal effect on the definition of the offence, because “without authorization” and “exceeds authorized access” are the operative phrases of the federal computer-access statute and “with the authorization of the owner or operator” is the operative phrase of the DMCA security testing exemption. A researcher inside a policy that deems their testing authorized is not defending against those elements. They are outside them.

The directive also constrains the policy in the other direction. Reporters must be able to submit anonymously: “a clear statement that reporters may submit a report anonymously.” The policy may not require personally identifiable information, may not “limit testing solely to vetted registered parties or U.S. citizens,” and must “provide authorization to the general public.” Those three lines are what separates a disclosure policy from an invitation list, and they are the reason the same document cannot quietly function as a private arrangement with a chosen few.

What changed in 2022, and what it binds

In May 2022 the Department of Justice revised its charging policy for the computer-access statute. The policy now lives in the Justice Manual and it is written as a direction to prosecutors, not as a rule about researchers.

The declination is stated plainly: “The attorney for the government should decline prosecution if available evidence shows the defendant’s conduct consisted of, and the defendant intended, good-faith security research.”

For the definition, the policy borrows from an unexpected place. It instructs that “the attorney for the government should apply the definition of good-faith security research recommended by the Register of Copyrights” in the eighth triennial section 1201 proceeding. The rendering in the Justice Manual is that good faith security research “means accessing a computer solely for purposes of good-faith testing, investigation, and/or correction of a security flaw or vulnerability, where such activity is carried out in a manner designed to avoid any harm to individuals or the public,” with the information used primarily to promote security or safety. The version currently codified in the copyright regulations says the activity must be “carried out in an environment designed to avoid any harm to individuals or the public.” Manner in one, environment in the other. A copyright rulemaking definition became the operative test in federal criminal charging policy, which is a strange piece of plumbing worth knowing about.

The same policy narrows the contract theory that had driven the hardest cases. “A CFAA prosecution may not be brought on the theory that a defendant exceeds authorized access solely by violating an access restriction contained in a contractual agreement or term of service with an Internet service provider or web service available to the general public.”

Three things about the scope of that instrument follow from its own text. It addresses federal criminal charging. It speaks to the attorney for the government. And it says nothing whatever about civil claims, about state prosecutions, or about the DMCA. An organization whose systems were tested retains whatever civil claims it had.

Scope

This note describes a binding operational directive, a Department of Justice charging policy, and a copyright regulation, and quotes what they say. It is a description of instruments, not legal advice. It does not say that any particular research is protected, does not evaluate any specific disclosure policy, and does not address what a researcher should do. A charging policy that directs prosecutors is a different kind of thing from a defense, and only a lawyer with the facts can say what applies to a given situation.

Why the specimen matters more than the label

The directive’s checklist is the useful artifact here, because it enumerates what such a document contains: the systems in scope, the testing that is authorized, who the authorization runs to, whether it extends to the general public or to a list, and whether the text deems activity authorized or only promises restraint. Those are properties of a document, visible on its face. Whether they add up to protection in any particular case is a legal question that reading the document does not settle, and that gap is the reason the phrase “safe harbor” carries more weight in conversation than it does on paper.

The private-sector analogue is a program’s terms, which are a different instrument again with different failure modes, covered in the note on bug bounty terms. The statutory elements that all of this is trying to reach are in the Computer Fraud and Abuse Act and, for the access-scope question specifically, in exceeds authorized access. On the receiving side, everything after the report lands is ordinary incident response.

Sources

Graph View

Backlinks