Blog

Log4Shell, SolarWinds Compromise, Heartbleed – cybersecurity breaches have become household names in recent years. These issues are costing organizations billions of dollars in prevention and remediation costs, yet at the same time they are becoming ever more common. Reacting to breaches after the fact is useful, but not enough; such reactions fail to protect users in the first place. Security needs to instead be baked into software before it’s released. Unfortunately, most software developers don’t know how to do this.

To alleviate this issue and improve access to cybersecurity training for everyone from developers to operations teams to end users, the Open Source Security Foundation (OpenSSF) has partnered with Linux Foundation Training & Certification to release a new, free, online training course, Developing Secure Software. Those who complete the course and pass the final exam will earn a certificate of completion valid for two years.

Geared towards software developers, DevOps professionals, software engineers, web application developers, and others interested in learning how to develop secure software, this course focuses on practical steps that can be taken, even with limited resources, to improve information security. The goal is to make it easier to create and maintain systems that are much harder to successfully attack, reduce the damage when attacks are successful, and speed the response so that any latent vulnerabilities can be rapidly repaired.

This course starts by discussing the basics of cybersecurity, such as what risk management really means. It discusses how to consider security as part of the requirements of a system, and what potential security requirements you might consider. It then focuses on how to design software to be secure, including various secure design principles that will help you avoid bad designs and embrace good ones. It also considers how to secure your software supply chain, that is, how to more securely select and acquire reused software (including open source software) to enhance security. 

The course also focuses on key implementation issues and practical steps that you can take to counter the most common kinds of attacks. Discussion follows on how to verify software for security, including various static and dynamic analysis approaches, as well as how to apply them (e.g., in a continuous integration pipeline). It also discusses more specialized topics, such as the basics of how to develop a threat model and how to apply various cryptographic capabilities. The course content mirrors that in the Secure Software Development program we offer with edX, but in a single course instead of three.

The self-paced course can be completed in about 14-18 hours and includes quizzes to test the knowledge gained. Upon completion, participants will receive a digital badge verifying that they have been successful in all required coursework and have learned the material. This digital badge can be added to resumes and social media profiles. 

Enroll today to start improving your cybersecurity skills and practices!

There was once a time when we marveled at the global nature of the open source user and contributor community, when it was a thrill to get a question or patch from an address ending in .nz or .jp or .cl., or to hear about your software running at the Vatican or the International Space Station. These days, it’s a given that the more popular an open source project is, the more likely its user and contributor community span continents and cultures. 

Well-run open source projects recognize that fact, and often take a series of steps to build their global user and contributor base. Those steps can include basic ones like ensuring Unicode and 8-bit-clean text handling in their UI, providing localization via resource bundles, or translating documentation. Others realize there’s often a human and cultural gap to cross, so they invest in growing local user communities and support forums, or flying core maintainers to present at conferences they might not otherwise reach. The hardest, but potentially the most important thing, is for projects to look at the pathways for users to become participants and contributors, everything from the forums and mailing lists to regular conference calls all can inadvertently create barriers for people in other time zones and who use other communication methods.

We are just beginning this journey at OpenSSF. To date the vast majority of active contributors are based in the US, with a smidge in Europe and Australia. However, the people we’d like to reach with the OpenSSF’s different guides, specifications, services and software are global, and we know there are potential contributors to our efforts everywhere too. To support that, you’ll see us start to prioritize things like moving meetings to more globally convenient times; investing in translations of our work products; and putting together more virtual (and eventually face-to-face) meetings focused on the global audience.

On Thursday, March 24th, at 11am Hong Kong time (also 8:30am IST, 11am SGT, 12pm Japan, Korea and 2pm Australia) we’ll be hosting a virtual event introducing OpenSSF to the Asia-Pacific audience. David Wheeler, Julian Gordon and I will be joined by VM Brasseur from Wipro to give an overview of what we’re doing and how people from the region can get involved. Please come if you’re at all interested!

If there’s other things you think we can do to be more globally accessible, don’t hesitate to jump on the OpenSSF Slack, we’d love to hear from you.

Thanks!

– Brian

Authors: Best Practices Working Group, Laurent Simon (Google), Azeem Shaikh (Google), and Jose Palafox (GitHub)

Today, two members of the Open Source Security Foundation, Google and GitHub, are partnering to release Scorecards V4, featuring a new GitHub Action, an added security check, and scaled up scans of the open source ecosystem.

The Scorecards project was launched last year as an automated security tool to help open source users understand the risks of the dependencies they consume. Though the world runs on open source software, many open source projects engage in at least one risky behavior—for example, not enabling branch protection, not pinning dependencies, or not enabling automatic dependency updates. Scorecards makes it simple to evaluate a package before consuming it: a scan run with a single line of code returns individual scores from 0 to 10 rating each individual security practice (“checks”) for the project and an aggregate score for the project’s overall security. Today’s release of a Scorecards GitHub Action makes it easier than ever for developers to stay on top of their security posture.

Helping Developers

Scorecards GitHub Workflow Action

Previously, Scorecards needed to be run manually to judge how changes to a project affected its security. The new Scorecards GitHub Action automates this process: once installed, the Action runs a Scorecards scan after any repository change. Maintainers can view security alerts in GitHub’s scanning dashboard and remediate any risky supply-chain practices introduced by the change. 

As shown in the example above, each alert includes the severity of the risk (low, medium, high, or critical), the file and line where the problem occurs (if applicable), and the remediation steps to fix the issue.

Several critical open source projects have already adopted the Scorecards Action, including Envoy, distroless, cosign, rekor, kaniko. The Action is free to use and can be installed on any public repository by following these directions.

New Checks

We’re continually adding new security checks to help developers assess risks to their projects. This release adds the License check, which detects the presence of a project license, and the Dangerous-Workflow check, which detects dangerous usage of the pull_request_target trigger and risks of script injections in GitHub workflows. Dangerous Workflow is the first Scorecards check with a “Critical” risk level rating, since these patterns are so easily exploited—with these workflows, a single pull request can introduce compromised code into a project. The new Scorecards check informs users of the existence of these vulnerabilities in their project and provides remediation guidance to fix the issue.

Scaling Up Data Availability

The Scorecards team runs weekly scans of a set of critical open source projects, creating snapshots of the security of the overall open source ecosystem at any given time. Over the past few months, we have increased the scale of scans from 50,000 projects to one million projects identified as most critical based on their number of direct dependencies, giving a more detailed view of the ecosystem and strengthening supply chain security as users see improved coverage of their dependencies. With Scorecards V4, the weekly scans now reflect the 0-10 rating scale for each repository rather than the pass-fail results of previous versions, adding more granularity to the data. The scan results are publicly available through the Scorecards API and on the OpenSSF metrics dashboard and Open Source Insights partner websites.

Growing the Community

Since our initial launch, we have been improving our codebase thanks to the expanding Scorecards community. In 2021, we grew to over 40 unique contributors, averaged over 16 commits per week (totalling 860 commits), and closed 270 issues. We warmly welcome new contributors; check out this list of good first-timer issues if you’d like to join in the fun. 

Here’s a few examples of projects that have adopted Scorecards:

“kaniko is a popular open source container image builder for Kubernetes, so it’s very important to maintain the security of the repository and the codebase. The ossf/scorecard Github Action takes care of this for us and continuously monitors the repository. It took less than 5 minutes to install and quickly analyzed the repo and identified easy ways to make the project more secure.” 

– Priya Wadhwa, Kaniko

“We rely on scorecards in distroless to ensure we follow secure development best practices. Secure source and config means safer base images for all our users.”

 – Appu Goundan, Distroless

“Scorecards provides us the ability to rapidly litmus test new dependencies in the Envoy project. We have found this a valuable step in vetting new dependencies for well known attributes and we have integrated Scorecards into our dependency acceptance criteria. Machine checkable properties are an essential part of a sound security process.”

 – Harvey Tuch, Envoy

Strengthening the Supply Chain 

We expect 2022 to be a year of growing awareness of the criticality of supply chain security. If your New Year’s resolution is to pay closer attention to your projects’ security, using the Scorecards GitHub Action is one of the easiest ways to get started. Just install the workflow on your repositories and follow the remediations instructions to address the issues that roll in. Each incremental improvement helps strengthen the open source ecosystem for everyone.

For additional information, head over to the release notes and, as always, please reach out with any questions or suggestions.

Today marks an important moment in the Linux Foundation’s history of engagement with public sector organizations. The White House convened an important cross-section of the Open Source developer and commercial ecosystem along with leaders and experts of many U.S. federal agencies to identify the challenges present in the open source software supply chain and share ideas on ways to mitigate risk and enhance resilience. 

At the meeting, the Linux Foundation and the Open Source Security Foundation (OpenSSF) represented their hundreds of communities and projects by highlighting collective cybersecurity efforts and sharing their intent to work with the administration across public and private sectors. 

Linux Foundation Executive Director Jim Zemlin said, “Safeguarding critical infrastructure includes securing the software that runs its banking, energy, defense, healthcare, and technology systems. When the security of a widely-used open source component or application is compromised, every company, every country, and every community is impacted. This isn’t a problem unique to the US government; it’s a global concern. We applaud the US government’s leadership in facilitating a stronger focus on open source software security and look forward to collaborating with the global ecosystem to make progress. In particular, the OpenSSF is our key initiative to address the broad set of open source software supply chain challenges, and it was very heartening to hear our work identified and endorsed by other participants in the meeting as a basis for further collaboration.” 

Executive Director of the Open Source Security Foundation, Brian Behlendorf commented, “During today’s meeting, we shared a set of key opportunities where, with sufficient commitments from everyone, we could make a substantial impact on the critical endeavors needed to protect and improve the security of our software supply chains. The open source ecosystem will need to work together to further cybersecurity research, training, analysis and remediation of defects found in critical open source software projects. These plans were met with positive feedback and a growing, collective commitment to take meaningful action. Following the recent log4j crisis, the time has never been more pressing for public and private collaboration to ensure that open source software components and the software supply chains they flow through demonstrate the highest cybersecurity integrity.”

Brian continued, “Through efforts such as our working groups on Best Practices, Identifying Critical Projects, Metrics and Scorecards, Project Sigstore, and more to be announced soon, the OpenSSF has already had an impact on many of the key areas discussed during today’s meeting. We are ready to further these efforts and welcome all new participants and resources that this conversation and further such conversations may bring.”

As someone who has spent their entire career in open source software (OSS), the Log4Shell scramble (an industry-wide four-alarm-fire to address a serious vulnerability in the Apache Log4j package) is a humbling reminder of just how far we still have to go. OSS is now central to the functioning of modern society, as critical as highway bridges, bank payment platforms, and cell phone networks, and it’s time OSS foundations started to act like it.

Organizations like the Apache Software Foundation, the Linux Foundation, the Python Foundation, and many more, provide legal, infrastructural, marketing and other services for their communities of OSS developers. In many cases the security efforts at these organizations are under-resourced and hamstrung in their ability to set standards and requirements that would mitigate the chances of major vulnerabilities, for fear of scaring off new contributors. Too many organizations have failed to apply raised funds or set process standards to improve their security practices, and have unwisely tilted in favor of quantity over quality of code.

What would “acting like it” look like? Here are a few things that OSS foundations can do to mitigate security risks:

1. Set up an organization-wide security team to receive and triage vulnerability reports, as well as coordinate responses and disclosures to other affected projects and organizations.
2. Perform frequent security scans, through CI tooling, for detecting unknown vulnerabilities in the software and recognizing known vulnerabilities in dependencies.
3. Perform occasional outside security audits of critical code, particularly before new major releases.
4. Require projects to use test frameworks, and ensure high code coverage, so that features without tests are discouraged and underused features are weeded out proactively.
5. Require projects to remove deprecated or vulnerable dependencies. (Some Apache projects are not vulnerable to the Log4j v2 CVE, because they are still shipping with Log4j v1, which has known weaknesses and has not received an update since 2015!)
6. Encourage, and then eventually require, the use of SBOM formats like SPDX to help everyone track dependencies more easily and quickly, so that vulnerabilities are easier to find and fix.
7. Encourage, and then eventually require, maintainers to demonstrate familiarity with the basics of secure software development practices.

Many of these are incorporated into the CII Best Practices badge, one of the first attempts to codify these into an objective comparable metric, and an effort that has now moved to OpenSSF. The OpenSSF has also published a free course for developers on how to develop secure software, and SPDX has recently been published as an ISO standard.

None of the above practices is about paying developers more, or channeling funds directly from users of software to developers. Don’t get me wrong, open source developers and the people who support them should be paid more and appreciated more in general. However, it would be an insult to most maintainers to suggest that if you’d just slipped more money into their pockets they would have written more secure code. At the same time, it’s fair to say a tragedy-of-the-commons hits when every downstream user assumes that these practices are in place, being done and paid for by someone else.

Applying these security practices and providing the resources required to address them is what foundations are increasingly expected to do for their community. Foundations should begin to establish security-related requirements for their hosted and mature projects. They should fundraise from stakeholders the resources required for regular paid audits for their most critical projects, scanning tools and CI for all their projects, and have at least a few paid staff members on a cross-project security team so that time-critical responses aren’t left to individual volunteers. In the long term, foundations should consider providing resources to move critical projects or segments of code to memory-safe languages, or fund bounties for more tests.

The Apache Software Foundation seems to have much of this right, let’s be clear. Despite being notified just before the Thanksgiving holiday, their volunteer security team worked with the Log4j maintainers and responded quickly. Log4j also has almost 8000 passing tests in its CI pipeline, but even all that testing didn’t catch the way this vulnerability could be exploited. And in general, Apache projects are not required to have test coverage at all, let alone run the kind of SAST security scans or host third party audits that might have caught this.

Many other foundations, including those hosted at the Linux Foundation, also struggle to do all this – this is not easy to push through the laissez-faire philosophy that many foundations have regarding code quality, and third-party code audits and tests don’t come cheap. But for the sake of sustainability, reducing the impact on the broader community, and being more resilient, we have got to do better. And we’ve got to do this together, as a crisis of confidence in OSS affects us all.

This is where OpenSSF comes in, and what pulled me to the project in the first place. In the new year you’ll see us announce a set of new initiatives that build on the work we’ve been doing to “raise the floor” for security in the open source community. The only way we do this effectively is to develop tools, guidance, and standards that make adoption by the open source community encouraged and practical rather than burdensome or bureaucratic. We will be working with and making grants to other open source projects and foundations to help them improve their security game. If you want to stay close to what we’re doing, follow us on Twitter or get involved in other ways. For a taste of where we’ve been to date, read our segment in the Linux Foundation Annual Report, or watch our most recent Town Hall.

Hoping for a 2022 with fewer four alarm fires,

Brian

Brian Behlendorf is General Manager of the Linux Foundation’s Open Source Security Foundation (OpenSSF). He was a founding member of the Apache Group, which later became the Apache Software Foundation, and served as president of the foundation for three years.

The Open Source Security Foundation (OpenSSF) Developer Best Practices Working Group has undertaken a project to improve the overall security and integrity of critical open source software projects and their supply chains.  Dubbed “The Great MFA Distribution Project”, the group is putting hardware multi-factor authentication (MFA) tokens into the hands of open source software (OSS) developers and providing them simple ways to integrate them into their projects’ daily workflows. These tokens are provided through the generous donation of multi-factor authentication tokens from OpenSSF members GitHub and Google.

Supply chain integrity is more important and prescient than ever.  Supply chain attacks have increased at rates that parallel the explosive growth of open source software development techniques and code.  The OpenSSF was formed in 2020 from a broad coalition of industry and open source security experts focusing on different aspects of improving the overall quality and security of OSS through deep collaboration with communities.  As the foundation grows and evolves, so does the scope of projects the group collaborates on.  The OpenSSF’s Great MFA Distribution Project is one of several active projects focused on securing OSS.

Through the use of MFA tokens a developer, contributor, or maintainer on an OSS project can add extra assurance of their identity as they engage with code and tooling within their projects instead of just using a username/password combination.  For example, these tokens will eliminate the problem of attackers using stolen passwords to “take over” OSS developer accounts to release subverted source code or packages. This helps improve the trustworthiness of this software for downstream consumers, strengthening the chain of custody and trustworthiness.

The Great MFA Distribution project has begun reaching out to a list of identified critical OSS projects and distribution of tokens will be underway during December.  The MFA Distribution project offers no-charge hardware tokens to OSS project developers and maintainers along with simple documentation on how these tools can be integrated into daily development activities.  Details on the project can be found in the Great MFA Distribution project repository.

On behalf of the OpenSSF community and staff, thank you to everyone who joined our quarterly town hall meeting today. If you weren’t able to attend the live presentation, check out the recording below and let us know if you have any questions or want to get more involved with any of the working groups or projects!

View the Zoom recording with chat, or watch the recording below.

The OpenSSF community is excited to chat more in-depth about several exciting project updates and recent announcements! We hope you’ll join us for our next community Town Hall, to be held Monday, November 15 at 10 a.m. PT (click here to see it in your local time).

This event is open to all – register now, then help us spread the word on Twitter and add the event to your calendar.

Imagine you have created an open source project that has become incredibly popular.  Thousands, if not millions, of developers worldwide, rely on the lines of code that you wrote. You have become an accidental hero of that community — people love your code, contribute to improving it, requesting new features, and encouraging others to use it. Life is amazing, but with great power and influence comes great responsibility.

When code is buggy, people complain. When performance issues crop up in large scale implementations, it needs to be addressed. When security vulnerabilities are discovered — because no code or its dependencies are always perfect — they need to be remediated quickly to keep your community safe.  

To help open source projects better address some of the responsibilities tied to security, many communities hosted by the Linux Foundation have invested countless hours, resources, and code into some important efforts. We’ve worked to improve the security of the Linux kernel, hosted Let’s Encrypt and sigstore, helped steward the ISO standardization for SPDX, and brought together a community building metrics for OSS health and risk through the CHAOSS project — among many others.

Today, we are taking steps with many leading organizations around the world to enhance the security of software supply chains. The Linux Foundation has raised $10 million in new investments to expand and support the Open Source Security Foundation (OpenSSF) and its initiatives. This cross-industry collaboration brings together an ecosystem to collectively identify and fix cybersecurity vulnerabilities in open source software and develop improved tooling, training, research, best practices, and vulnerability disclosure practices. We are also proud to announce that open source luminary, Brian Behlendorf, will serve the OpenSSF community as General Manager. 

Financial commitments for OpenSSF include Premier members such as AWS, Cisco, Dell Technologies, Ericsson, Facebook, Fidelity, GitHub, Google, IBM, Intel, JPMorgan Chase, Microsoft, Morgan Stanley, Oracle, Red Hat, Snyk, and VMware. Additional commitments come from General members, including Aiven, Anchore, Apiiro, AuriStor, Codethink, Cybertrust, Deepfence, Devgistics, DTCC, GitLab, Goldman Sachs, JFrog, Nutanix, StackHawk, Tencent, TideLift, and Wind River.

To learn more about how to join the OpenSSF or to get involved in one of its six working groups, listen in to this brief introduction from Brian Behlendorf recorded this week at KubeCon:https://www.youtube.com/embed/Mjsb6Z1Weto?feature=oembed&wmode=opaque&rel=0

In 2021, the Linux Foundation and its community will continue to support education and share resources critical to improving open source cybersecurity.  For example, this week, we also hosted SupplyChainSecurityCon, where the SLSA and sigstore projects were heavily featured.

If you are an open source software developer, user, or other community participant who just wants to help further protect the software that accelerates innovation around the world, please consider joining one of our six OpenSSF working groups, or suggest a new working group that addresses gaps in software supply chain security needs.

You can follow the latest news from OpenSSF here on our blog, Twitter (@TheOpenSSF), and LinkedIn.