Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

3/9/2021
03:25 PM
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
50%
50%

Linux Foundation Debuts Sigstore Project for Software Signing

Sigstore aims to improve the open source software supply chain by simplifying the process of cryptographic software signing.

The Linux Foundation today announced its launch of Sigstore, a new nonprofit initiative that aims to improve open source software supply chain security by making it easier for developers to adopt cryptographic signing for different components of the software development process.

Related Content:

6 Open Source Tools for Your Security Team

Special Report: How IT Security Organizations Are Attacking the Cybersecurity Problem

New From The Edge: Realistic Patch Management Tips, Post-SolarWinds

Sigstore will be free for software providers and developers, who can use it to securely sign software artifacts such as release files, container images, binaries, and bill-of-material manifests. Signing materials are then stored in a tamper-proof public log. The service's code and operation tooling will be fully open source and maintained and developed by the Sigstore community. 

Founding members include Red Hat, Google, and Purdue University. The idea for the service came from Luke Hinds, security engineering lead in Red Hat's Office of the CTO. He pitched the concept to Google software engineer Dan Lorenc, and the two began to work on it. Now the Sigstore project has a "small but agile community" working on its development, Lorenc says.

Software supply chains face security risks. Users are exposed to targeted attacks, as well as account and cryptographic key compromise. Keys are difficult for software maintainers to manage. Software projects often have a list of keys in use, and maintainers must handle the keys of people no longer involved. These public keys are often stored on git repo readme files or websites, where they may be susceptible to tampering and don't securely convey trust. 

Software signing is meant to convey trust. The process of digitally signing software is meant to provide evidence that the code comes from a known developer or software vendor and hasn't been tampered with. This gives users confidence they're using code from a trusted source.

But few open source projects cryptographically sign software artifacts. "We spent almost the last nine months or so talking to different open source maintainers and communities on how they're doing this, if they're not doing this [then] why not, and then user perspective: Do you care if people are signing? How do you know what keys to check against?" Lorenc says.

Their team found "a huge amount lacking in the space," he continues. Most software projects aren't doing anything at all to improve secure software signing. The tool sets many have used in the past require signing one other's keys in person, which doesn't work for remote developers, Hinds adds. Sigstore aims to both ease the adoption, and lower the risk, of software signing.

"When you take on signing, you take on a lot of risk as well, because … you have to protect a private key and this really exposes the risk of a project," Hinds continues. "It's a kind of chicken and egg: The need to sign things to provide assurance to their users, but once they do start to sign things, they up the ante around their attack surface and a possible key compromise."

How It Works
To make the process simple, Sigstore relies on the OpenID authentication protocol to connect certificates to identities. This allows developers to use security controls they already have, such as multifactor authentication, one-time passwords, and hardware token generators. 

Existing signing solutions essentially work to build a whole new identity system, and give users private keys they're responsible for protecting, Lorenc explains. Sigstore "piggybacks off of an existing identity system that everybody already knows how to work with, that's already federated, and already gets all the attention of security professionals at organizations." 

Sigstore users use its tooling to create ephemeral short-lived key pairs. Its public key infrastructure (PKI) service provides a signing certificate following the successful OpenID connect grant. From there, certificates are recorded into a certificate transparency log, and software signing materials go to a signature transparency log, Sigstore explains on its website.

These transparency logs are a public and tamper-proof record of sign-in events, Hinds notes. "By having that available, anybody can audit or monitor these logs for who's signing what. It makes it publicly transparent," he adds. Anyone can perform queries using an artifacts digest or return entries that are signed by a specific public key or email address. 

Because the keys are short-lived, there is no concern about keys potentially being left and vulnerable to compromise, Hinds says. After that, there's nothing left for the developer to manage and all activity is recorded in the log. 

Today marks the launch of the foundation, Hinds says. While the transparency log is fully functional, Sigstore isn't available to developers just yet. As for what developers will be able to sign and store, the team is first aiming for generic release artifacts such as compiled binaries and container images. Later on, they plan to explore other formats and manifest signing.

The team hopes Sigstore will be made available later this year, though an official date has not yet been determined.

Kelly Sheridan is the Staff Editor at Dark Reading, where she focuses on cybersecurity news and analysis. She is a business technology journalist who previously reported for InformationWeek, where she covered Microsoft, and Insurance & Technology, where she covered financial ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
News
US Formally Attributes SolarWinds Attack to Russian Intelligence Agency
Jai Vijayan, Contributing Writer,  4/15/2021
News
Dependency Problems Increase for Open Source Components
Robert Lemos, Contributing Writer,  4/14/2021
News
FBI Operation Remotely Removes Web Shells From Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/14/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-22540
PUBLISHED: 2021-04-22
Bad validation logic in the Dart SDK versions prior to 2.12.3 allow an attacker to use an XSS attack via DOM clobbering. The validation logic in dart:html for creating DOM nodes from text did not sanitize properly when it came across template tags.
CVE-2021-27736
PUBLISHED: 2021-04-22
FusionAuth fusionauth-samlv2 before 0.5.4 allows XXE attacks via a forged AuthnRequest or LogoutRequest because parseFromBytes uses javax.xml.parsers.DocumentBuilderFactory unsafely.
CVE-2021-3287
PUBLISHED: 2021-04-22
Zoho ManageEngine OpManager before 12.5.329 allows unauthenticated Remote Code Execution due to a general bypass in the deserialization class.
CVE-2021-31547
PUBLISHED: 2021-04-22
An issue was discovered in the AbuseFilter extension for MediaWiki through 1.35.2. Its AbuseFilterCheckMatch API reveals suppressed edits and usernames to unprivileged users through the iteration of crafted AbuseFilter rules.
CVE-2021-31548
PUBLISHED: 2021-04-22
An issue was discovered in the AbuseFilter extension for MediaWiki through 1.35.2. A MediaWiki user who is partially blocked or was unsuccessfully blocked could bypass AbuseFilter and have their edits completed.