LFD121 is a free course offered by OpenSSF that takes about 14-18 hours to complete. Any student who passes the final exam gets a certificate that is valid for two years.  

The course is broken down into three parts. The first part covers the basics of secure software development, like how to implement secure design principles and how to secure the software supply chain. Part two covers implementation of those basics and then part three finishes up with security testing and also covers more specialized topics like threat modeling, fielding, and formal methods for verifying that software is secure. 

The new interactive labs are not required for completing the course, but do enhance the experience, OpenSSF explained. The labs launch directly in the web browser, meaning no additional software needs downloading. 

Each lab involves working through a specific task, such as validating input of a simple data type. “Learning how to do input validation is important,” said David Wheeler, director of open source supply chain security, at OpenSSF. “Attackers are *continuously* attacking programs, so developers need to learn to validate (check) inputs from potential attackers so that it’s much harder for attackers to malicious inputs into a program.”

Each lab includes a general goal, background on the issue, and information about the specific tasks. Students will work through a pre-written program that has some areas that will need to be filled in by the student. 

According to Wheeler, the goal of all of the labs isn’t to learn specific technologies, but to learn core concepts about writing secure software. For example, in the input validation lab, the student only needs to fix one line of code, but that line of code is the one that does the validation, and therefore, is critically important. 

“In fact, without the input validation line to be crafted by the user, the code has a vulnerability (specifically a ‘cross-site scripting vulnerability’),” said Wheeler.

Students can also get help throughout the lab by requesting context-specific hints that take into account where they are stuck. Wheeler explained that the hints help students progress through the labs even if they’re not familiar with the particular programming language used in the lab. 

The post OpenSSF updates its Developing Secure Software course with new interactive labs appeared first on SD Times.

The report also found that 55% of the total lines of code for all projects were written in a memory-unsafe language. 

According to the report, memory-unsafe languages — such as C or C++ — place the responsibility of managing memory use and allocation on developers, which can lead to memory-safety vulnerabilities like buffer overflows and use after free if they make a mistake. Memory-safe languages shift that responsibility to the compiler or interpreter and can significantly reduce the opportunity to introduce memory-safety vulnerabilities, which have led to vulnerabilities like Morris Worm, Slammer Worm, Heartbleed, and BLASTPASS. 

“By using memory-safe languages, programmers can focus on producing higher-quality code rather than perilously contending with low-level memory management,” said Omkhar Arasaratnam, GM at the OpenSSF.

This new report follows the White House Office of the National Cyber Director’s (ONCD) call earlier this year on technology leaders to adopt memory-safe languages. 

“We, as a nation, have the ability – and the responsibility – to reduce the attack surface in cyberspace and prevent entire classes of security bugs from entering the digital ecosystem but that means we need to tackle the hard problem of moving to memory safe programming languages,” said National Cyber Director Harry Coker at the time.  

According to Chris Hughes, CISSP, chief security advisor at Endor Labs and Cyber Innovation Fellow at CISA, one of the reasons why so many projects are written in memory-unsafe languages is that for many years those languages were widely adopted and it’s only been recently that there’s been a move to encourage developers to utilize memory-safe languages. 

He explained that it will be difficult to transition existing projects to memory-safe languages because of the resources, effort, and expertise required, which maintainers of the projects may not have.  

“That said, there are also opportunities for organizations to help facilitate the transition through resources including monetary incentives, as well as potentially development support to facilitate the transition,” said Hughes. “Of course, there still remains issues with third-party and transitive dependencies as discussed in the report, meaning even if the projects were re-written, they would need to conduct dependency analysis and ensure that transitive dependencies are also accounted for when it comes to memory safety. Lastly, efforts would need to be made to ensure the developers and maintainers implement secure coding practices to ensure memory safety safeguards aren’t undermined.”

You may also like…

White House recommends software be written in memory safe languages to improve cybersecurity

Are developers and DevOps converging?

The post CISA report highlights need to transition to memory-safe languages appeared first on SD Times.

The Cyber Resilience Act (CRA) establishes security requirements for hardware and software products for sale in the EU.  

Together, the OpenSSF and Eclipse Foundation, will contribute to the development of security standards. Their goal is to come up with standards that are practical, effective, and reflect the latest open source security advancements. 

They will work closely with policymakers, industry leaders, and security experts to ensure that the standards and specifications meet real-world needs. 

“The E.U. CRA seeks to fortify cybersecurity across the software supply chain by implementing stringent security measures and compliance standards for software products. Recognizing the critical role of open source software in the global digital infrastructure, the OpenSSF’s participation is poised to influence the creation of robust technically correct security specifications,” OpenSSF wrote in a blog post. 

The post OpenSSF teams up with Eclipse Foundation to define specifications for the EU’s Cyber Resilience Act appeared first on SD Times.

The project was created jointly by the Open Source Security Foundation (OpenSSF), Cybersecurity and Infrastructure Security Agency (CISA), and the Department of Homeland Security Science and Technology Directorate (DHS S&T). 

Protobom allows companies to read software bill of materials (SBOM) data, create their own SBOMs, and translate SBOMs into different standard formats. 

According to OpenSSF, there are many SBOM formats and schemas out there, which can be challenging for companies. The goal of the new project is to provide a “format-neutral data layer on top of the standards that lets applications work seamlessly with any kind of SBOM.”

OpenSSF also explained that by integrating Protobom into applications that link SBOM and vulnerability information, organizations will be able to more quickly access the necessary patches and mitigations to keep their software supply chains safe. 

“Vulnerabilities in software are a key risk in cybersecurity, with known exploits being a primary path for bad actors to inflict a range of harms. By leveraging SBOMs as key elements of software security, we can mitigate the risk to the software supply chain and respond to new risks faster, and more efficiently,” said Allan Friedman, senior advisor and strategist at CISA. “Protobom is a step towards greater efficiency and interoperability by translating across the widely used formats so that tools and organizations can focus on what’s important. It is a positive solution that helps shape a more transparent software-driven world.”

Omkhar Arasaratnam, general manager of OpenSSF, added: “Protobom not only simplifies SBOM creation, but also empowers organizations to proactively manage the risk of their open source dependencies. The security of open source software requires partnership between the public sector, private sector and the community. The OpenSSF is proud to be a part of this mission.”

The post OpenSSF, CISA, and DHS collaborate on new open-source project for creating SBOMs appeared first on SD Times.

This collaborative effort, initiated by Kusari, Google, and Purdue University, is designed to manage dependencies and offer actionable insights into the security of software supply chains. It has support from entities in the financial services and technology sectors, such as Yahoo!, Microsoft, Red Hat, Guidewire, and ClearAlpha Technologies.

GUAC addresses the growing concerns over software security and the integrity of software supply chains, exacerbated by the increasing frequency of software attacks and the widespread adoption of open-source tools. By serving as a reliable source of truth, GUAC aims to bridge the information gap between developers and security teams, facilitating a mutual understanding of software vulnerabilities, compliance issues, and threat detection.

Since its beta launch in May of the previous year, GUAC has swiftly established itself as an essential tool for gaining comprehensive insights into software supply chains. The project has a community of 50 contributors, 300 members, and has garnered over 1,100 stars on GitHub.

GUAC’s technology enables a thorough analysis of software components, including first-party, third-party, and open-source software, by aggregating security metadata into a graph database. 

This allows users to trace connections, ensure compliance, identify data gaps in their software supply chain, and bolster threat detection and response capabilities. The platform supports a wide range of data sources, including Software Bill of Materials (SBOMs) in SPDX and CycloneDX formats, SLSA and in-toto attestations, and metadata from various cloud services and external repositories.

By converting diverse software supply chain metadata into a structured and analyzable format, GUAC enhances visibility into software dependencies and the integrity of software components. Its flexible and extensible architecture accommodates data from local file systems, cloud storage services, and external package repositories, further enriched by additional metadata sources. This comprehensive approach positions GUAC as a useful tool in securing software supply chains against emerging threats, fostering a safer software ecosystem for developers and organizations alike.

The post SD Times Open-Source Project of the Week: Guac appeared first on SD Times.

According to OpenSSF, the Alpha-Omega project has become a pivotal player in enhancing the security infrastructure of open-source software, reflecting a proactive approach to cybersecurity in the tech community. Alpha-Omega is sponsored by Google, Microsoft, and AWS.  

Throughout 2023, the Alpha-Omega project awarded 10 grants to 8 different organizations, amounting to a total of $2,841,968. This marked a significant increase in the average grant size to $355,246, up by 38% compared to the previous year. 

The cumulative grants extended by Alpha-Omega have now reached $4.9 million, showcasing the project’s expanding commitment to fortifying open-source software against potential security threats.

Beneficiaries include the Python Software Foundation, the Eclipse Foundation, the Rust Foundation, and OpenJS. The specific projects that received grants in 2023 were Eclipse, NodeJS, Rust, Homebrew, OpenSSL, OpenRefactory, Prossimo, and the Linux Kernel. 

This strategic allocation of resources not only strengthens the security posture of these critical platforms but also underscores the Alpha-Omega project’s role in safeguarding the integrity of open-source software at a fundamental level, according to OpenSSF.

Another key finding from the report is that Alpha-Omega grants are now being followed by direct institutional budgets and fundraising for security staffing and projects. Also, Sigstore adoption continues to grow across the open-source ecosystem, which the organization believes to be a result of the increased funding from Alpha-Omega. For instance, the Python Software Foundation now signs Python and CPython releases with Sigstore, with more ecosystem adoption coming soon.

Lastly, security champions that were funded by Alpha-Omega are improving security culture in their respective communities.

The post OpenSSF shares progress for its Alpha-Omega project in 2023 appeared first on SD Times.

“Currently, each open source package repository has its own approach to handling malicious packages. When a malicious package is reported by the community, it is common for the package repository’s security team to remove the package and its associated metadata. Unfortunately, these actions often occur without any public record. Discovering what malicious packages exist requires piecing together data from many disparate public sources, or through proprietary threat intelligence feeds,” Caleb Brown, senior software engineer on the Google Open Source Security Team and Jossef Harush Kadouri, head of software supply chain security at Checkmarx, wrote in a blog post. 

The Malicious Packages repository acts as a public database where reports of malicious packages are stored. 

OpenSSF believes that having a public repository of this information will “stop malicious dependencies from moving through CI/CD pipelines, refine detection engines, scan for and prevent usage in environments, or accelerate incident response,” Brown and Kadouri explained. 

Reports are stored using the Open Source Vulnerability (OSV) format, which makes it easy to use with tools like osv.dev API, the osv-scanner tool, and deps.dev. 

The project sources data from Checkmarx security, exports of malicious packages that are tracked by GitHub, and the Package Analysis project, which looks at behaviors, such as what files the package accesses, what addresses it connects to, and what commands it runs. This helps it determine whether a package is behaving in a malicious way. It also tracks changes in behavior over time, which can help identify previously safe packages that turned malicious at some point.

The post OpenSSF launches Malicious Packages repository to track reports of compromised open source packages appeared first on SD Times.

Similar to the Agile Manifesto, OSCM is based on core values and comprises 15 guiding principles for using open source. It is designed to be a continuously evolving document, according to the Open SSF. 

Open Source Software (OSS) is a valuable resource that has greatly enhanced efficiency and innovation. However, not all OSS projects are the same. Some are poorly maintained, lack security standards, or carry risks. Just like any software, OSS has its flaws. Despite this, most organizations lack a strategy for consuming OSS effectively, according to the OpenSSF.

Unlike the scrutiny applied to third-party software, OSS often isn’t subject to the same level of evaluation for security, code quality, and licensing. This oversight is concerning since the risks associated with OSS can be significant, according to the OpenSSF End Users Working Group in a blog post. While third-party software is unlikely to contain malicious content, for those unaware of the intricacies of OSS, the moment of download is where risks emerge.

“We have observed that 96% of the time when a vulnerable component is downloaded, there is already a fixed version available, and nearly two years [after] log4shell, 30% of the downloads are of the known vulnerable versions. This is supporting evidence that the large amounts of open source software is consumed without a defined process or awareness,” Brian Fox, co-founder and CTO at Sonatype, told SD Times. 

The OpenSSF End Users Working Group took on the task of manifesting the change they wished to observe. This initiative acted as a seed sown during meaningful discussions. Over time, this seed evolved into what is now the Open Source Consumption Manifesto.

“The intention of the OSCM isn’t dogma. In fact, we aim for it to be the opposite. It represents an effort from weeks of conversation with input from many disciplines. This resulted in a collaborative collection of best practices forged through experience. And by experience, we mean our own failures and successes,” OpenSSF stated in the blog post. “The OSCM carries an intention of inclusion. It has changed over the course of our discussions, and we invite your future changes as well. Most of all, we hope the values and principles contained in the OSCM prove helpful. And that it serves as a guide to better open source consumption in your organization.”

One of the key points in the manifesto includes improving open-source consumption via audit and quarantine functionality for components matching known vulnerabilities and malicious packages.

“The only way to counter the intentionally malicious component threat is to have systems in place to monitor what components are being consumed. Pairing that with data and behavioral feeds allows your systems to make real time decisions on if something should be allowed, or quarantined pending deeper analysis,” Fox added. “This can buy time for confirmation of actual malicious intent. I like to compare this to credit card fraud systems that evaluate your transactions in real time and make a judgment call to allow, deny or send you a text to confirm if a transaction is outside of your typical spending patterns.”

To begin their observability journey, organizations should first list their applications based on their importance. Following this, they should compile an inventory of the OSS used within those applications, often done through software bills of materials, and identify the different suppliers. Without these steps, addressing the 96% problem mentioned earlier is challenging. Many development teams currently lack these essential elements, according to Fox. 

Next, it’s advisable to pinpoint instances where you might be employing multiple suppliers for a single function, like using various logging frameworks. Following this assessment, organizations should determine the most suitable suppliers by evaluating their secure software development practices. This evaluation should consider factors such as known vulnerabilities, software age, popularity, average time for fixing issues, and more, he added. 

“Each organization will be different though, and will need to make its own choices based on the analysis above. However, there are some obvious points like finding known critical vulnerabilities in an application that manages PII data would be outside most risk tolerances,” Fox said. “With all of the above, you can build the foundation of an OSS consumption policy. But you’re only part of the way there. That needs to be integrated across the SDLC, from development to CI/CD, and often most importantly, release.”

The full list of points in the manifesto is available here.

The post OpenSSF launches Open Source Consumption Manifesto appeared first on SD Times.

Here are highlights of the event so far: 

AWS open sources Cedar policy language and SDK  

The Cedar language enables you to set permissions in your applications using easy-to-understand policies. By making use of Cedar, application teams can decouple access control from application logic. 

It supports role-based access control and attribute-based access control, and was developed using verification-guided development, which ensures Cedar is correct and secure. 

The language’s SDKs are also being made available, which include libraries for creating and evaluating policies. 

AWS hopes that by open sourcing the language, they can foster more innovation in the industry around fine-grained access management and make access control more accessible to all. 

AWS also announces new open-source fuzzing framework

According to AWS, current fuzzing practices require large codebases to be refactored in order to work properly. The new framework, Snapchange, allows targets to undergo fuzz testing with minimal modifications.

Built in Rust, Snapchange enables developers to build fuzzers that replay snapshots of physical memory in a KVM virtual machine.

SPDX Release Candidate 3.0 now available

Software Package Data Exchange (SPDX) is an open source standard for communicating the information in a bill of materials. It is currently hosted by the Linux Foundation. 

In RC 3.0, there are now six unique profiles that are designed for popular use cases, with the goal being that SPDX better meets the needs of the industry. The profiles were created based on community input and include specifications for security, licensing, AI, datasets, and software packaging build processes. 

According to the Linux Foundation, the United States’ executive order on cybersecurity and Europe’s Cyber Resiliency Act served as inspiration for the need to have an international standard for supply chain security, which SPDX hopes to be. 

OpenSSF gets major funding from Google and Microsoft, new members

Through its Alpha-Omega Project, OpenSSF has recently received $2.5 million from Google and $2.5 million from Microsoft. 

OpenSSF also announced that Hitachi, Lockheed Martin, Salesforce, and SAP have become general members.

The foundation also announced that Omkhar Arasaratnam will be its new general manager and Brian Behlendorf will be chief technology officer. 

Meta joins the OpenJS Foundation

The OpenJS Foundation provides support for the open source JavaScript community. With Meta joining the foundation as a Gold Member, they will be able to contribute and advocate in the community further.

Meta had already been highly involved with the open source JavaScript community, through its projects React, Jest, and Flow. Jest is an open source testing framework, which Meta contributed to the OpenJS Foundation last year. 

“The broader JavaScript ecosystem benefits from Meta becoming an OpenJS Foundation member. In fact, we’ve already been working together in multiple different ways, and this makes official what has already been a great relationship,” said Shayne Boyer, OpenJS Foundation Board Director. “

The post Open Source Summit: AWS open sources Cedar, SPDX Release Candidate 3.0, and OpenSSF updates appeared first on SD Times.

SLSA’s framework is split into several different levels that describe increasing security severity so users can feel confident that software has not been tampered with and can be traced back to its source.

“The OpenSSF is working hard to put more rigor into the software development process,” said Brian Behlendorf, general manager of the OpenSSF. “The stable release of SLSA v1.0 is an important milestone in improving software supply chain security and providing organizations with the tools they need to protect their software.”

According to the company, SLSA’s specifications can be helpful for software consumers and producers alike. Producers can follow the guidelines to increase the security of their software supply chain, and consumers can use SLSA to make choices about whether to trust a software package.

With SLSA, users gain a common vocabulary to speak about software supply chain security, a method for assessing upstream dependencies by determining how trustworthy the artifacts a customer uses are, and a checklist designed to help improve the security of the software being developed.

Furthermore, this release provides a way to measure developers’efforts towards compliance with Executive Order Standards in the Secure Software Development Framework.

To get started using SLSA, visit the website.

The post Version 1.0 of SLSA provides specifications for software supply chain security appeared first on SD Times.