GitHub is releasing a new feature that allows security researchers and developers to work together quickly and privately to resolve vulnerability reports.
The private vulnerability reporting channel is an effort to make it easier for researchers to submit bug reports to developers and also give developers a single, simple way to communicate with researchers. Until now, researchers who wanted to report a bug to the maintainer of a GitHub repo had limited options. They could either open an issue for the specific repo or maybe email the maintainer, both of which could be cumbersome and lacked any security. The new feature provides a secure channel for the two parties to communicate about vulnerability reports without doing it publicly or resorting to a lengthy email thread.
GitHub announced a public beta of the program in November, and since then more than 30,000 organizations have turned the feature on for more than 180,000 repos on the platform. Organizations can enable private vulnerability reporting across all of their projects with one setting and the feature allows maintainers to send new reports to third-party vulnerability management applications automatically. There’s also an API that researchers can use to open new bug reports on multiple repositories at once.
In addition to the private vulnerability reporting tool, GitHub also is releasing a feature that allows developers to provide data about the provenance of their projects on npm, the package repository that GitHub manages. By including a special provenance flag in their packages, developers can give users a verifiable link to the source code repository and more confidence that the package is what it claims to be. This move is another step in the process of reducing the possibility of a supply chain attack against packages, something that is not an everyday occurrence but does happen.
“Attacks like these are seldom carried out by compromising the source code directly, but are more often the result of compromised credentials that are then used to publish a malicious version. The intrinsic transparency of the open source model instills a good degree of trust in the source code itself. The fact that we can all see the source and audit any changes decreases the chance that malicious code remains undetected. However, trust in the source code does not translate into trust in the published package,” Brian DeHamer, senior software engineer and Philip Harrison, staff software engineer, said in a post.
“In order to increase the level of trust you have in the npm packages you download from the registry you must have visibility into the process by which the source was translated into the published artifact. Our goal for the npm ecosystem is to bring the same level of transparency we have with the open source code itself to the process by which that code is built and published.”
To take advantage of the provenance feature, a package maintainer needs to use a trusted CI/CD platform. Once a build is triggered, GitHub will sign the provenance statement for it using the Sigstore project’s Fulcio certificate authority.
“As part of the package provenance generation, we create a single-use keypair to sign the provenance statement and then make a call to Sigstore’s Fulcio CA requesting a signing certificate which binds that key to the identity of the CI job. No one needs to manage the key (it’s deleted as soon as the signature is generated) but anyone presented with the signing certificate can verify the signature and also see the identity of the CI job responsible for creating it,” DeHamer and Harrison said.
After that, GitHub uploads the provenance attestation to Sigstore’s Rekor service, which keeps a public, tamper-evident ledger of the metadata of the signed package.
