Artifacts in GitHub are files or collections of files that were created during a workflow run, such as build or test output. 

Attestations include a link to the workflow associated with the artifact, along with other relevant information like its repository, organization, environment, commit SHA, and triggering event. 

According to GitHub, Artifact Attestations are powered by Sigstore, which is an open source project that allows software artifacts to be signed and verified to promote greater software integrity. 

Along with this general availability release, GitHub also is now offering a new way to build Kubernetes admission controllers that allows developers to validate attestations from within Kubernetes clusters. According to GitHub, this ensures that only properly validated artifacts get deployed.

“By integrating Artifact Attestations into your GitHub Actions workflows, you enhance the security of your development and deployment processes, protecting against supply chain attacks and unauthorized modifications,” GitHub wrote in a blog post. 

You may also like…

Sonatype shines light on current state of supply chain security in latest report

OpenSSF, CISA, and DHS collaborate on new open-source project for creating SBOMs

The post GitHub improves supply chain security with general availability of Artifact Attestations appeared first on SD Times.

The first new addition is Red Hat Trusted Artifact Signer, now generally available, which allows developers to cryptographically sign and verify application artifacts with a keyless certificate authority. 

According to Red Hat, the benefit of this new offering is that it enables organizations to be more confident about the integrity of software without having to manage a centralized key management system. 

Next, the company announced Red Hat Trusted Profile Analyzer, also now generally available, which provides a single source of truth for documentation like Software Bill of Materials (SBOMs) and Vulnerability Exploitability Exchange (VEX).

And finally, Red Hat Trusted Application Pipeline, now in beta, incorporates supply chain security capabilities into software templates that developers use. The company explained that this new offering will provide more traceability and auditability throughout the CI/CD pipeline. 

“Organizations are seeking to mitigate the risks of constantly evolving security threats in their software development – to keep and grow trust with users, customers and partners,” said Sarwar Raza, vice president and general manager of the Application Developer Business Unit at Red Hat. “Red Hat Trusted Software Supply Chain is designed to seamlessly bring security capabilities into every phase of the software development life cycle. From code time to runtime, these tools help increase transparency and trust and give DevSecOps teams the ability to lay the groundwork for a more secure enterprise without impacting developer velocity or cognitive load.”

The post Red Hat Trusted Software Supply Chain gets updated with three new offerings appeared first on SD Times.

This is compared to around 75% for JavaScript services, 64% for Python, and 50% for .NET. The average for all languages studied was 47%

The company found that Java services are also more likely to be actively exploited compared to other languages. Fifty-five percent have suffered from this, compared to a 7% average for other languages.

Datadog believes this may be due to the fact that there are many prevalent vulnerabilities in popular Java libraries, such as Tomcat, Spring Framework, Apache Struts, Log4j, and ActiveMQ. 

“The hypothesis is reinforced when we examine where these vulnerabilities typically originate. In Java, 63 percent of high and critical vulnerabilities derive from indirect dependencies— i.e., third-party libraries that have been indirectly packaged with the application. These vulnerabilities are typically more challenging to identify, as the additional libraries in which they appear are often introduced into an application unknowingly,” Datadog wrote in the report.

The company says this serves as a reminder that developers need to consider the full dependency tree when scanning for application vulnerabilities, not just the direct dependencies.

The second major finding of the report is that the largest number of exploitation attempts is done by automated security scanners, but that most of those attacks aren’t harmful and are just a source of noise for companies trying to defend against attacks.

Only 0.0065 percent of attacks performed by automated security scanners actually triggered vulnerabilities. 

Given the prevalence of these attacks but their harmlessness, Datadog believes this underscores the need for a good system for prioritizing alerts. 

According to the report, over 4,000 high and 1,000 critical vulnerabilities were discovered by the CVE project last year. However, research published in the Journal of Cybersecurity in 2020 found that only 5 percent of vulnerabilities are ever actually exploited. 

“Given these numbers, it’s easy to see why practitioners are overwhelmed with the amount of vulnerabilities they face, and why they need prioritization frameworks to help them focus on what matters,” Datadog wrote. 

Datadog found that organizations who have made efforts to address their critical vulnerabilities have success in removing them. Sixty-three percent of organizations that had a critical CVE at one point no longer have any, and 30% have seen the number of critical vulnerabilities reduced by half.  

The company recommends that organizations prioritize vulnerabilities based on if the impacted service is publicly exposed, the vulnerability is running in production, or there is publicly available code for the exploit. 

“While other vulnerabilities might still carry risk, they should likely be addressed only after issues that meet these three criteria,” Datadog wrote. 

Other interesting findings in Datadog’s report are that lightweight container images lead to fewer vulnerabilities, adoption of infrastructure as code is high, manual cloud deployments are still widespread, and usage of short-lived credentials in CI/CD pipelines is still low.

The post Report: Java is the language that’s most prone to third-party vulnerabilities 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.

Black Duck Supply Chain Edition does software composition analysis (SCA) that makes use of a number of security analysis techniques to determine the components in a piece of software, such as package dependency, CodePrint, snippet, binary, and container analysis. 

Customers can import SBOMs of their third-party components and automatically catalog the components found within. It performs continuous risk analysis on both internal SBOMs and the SBOMs of third-party components. 

This also allows it to identify not just security issues, but issues with licenses of third-party components. This includes analyzing AI-generated code and detecting if any part of it might be subject to license requirements.

The tool also performs post-build analysis that can help detect malware or potentially unwanted applications. 

SBOMs can be exported in SPDX or CycloneDX formats, which makes it easier to meet customer, industry, or regulatory requirements, according to Synopsys. 

“With the rise in software supply chain attacks targeting vulnerable or maliciously altered open source and third-party components, it’s critical for organizations to understand and thoroughly scrutinize the composition of their software portfolios,” said Jason Schmitt, general manager of the Synopsys Software Integrity Group. “This requires constant vigilance over the patchwork of software dependencies that get pulled in from a variety of sources, including open source components downloaded from public repositories, commercial software packages purchased from vendors, code generated from AI coding assistants, and the containers and IT infrastructure used to deploy applications. It also requires the ability to detect and generate actionable insights for a wide range of risk factors such as known vulnerabilities, exposed secrets, and malicious code.”

The post Synopsys hopes to mitigate upstream risks in software supply chains with new SCA tool appeared first on SD Times.

The company has access to open-source package intelligence data through partnerships with thousands of open-source projects. It pays the maintainers of those projects to follow secure development practices, like the ones outlined in the NIST Secure Software Development Framework and the OpenSSF Scorecards project.

Tidelift also aggregates data from upstream package managers and source repositories into a centralized format. This data is then analyzed by Tidelift’s data team, which provides contextual insights on it.

Tidelift Subscription also includes a Software Bill of Materials feature to enable companies to build a list of all the components that are in use. 

It also includes capabilities to help companies meet the upcoming compliance requirements from the U.S. government on supply chain security. These include a standardized attestations report and the ability to dynamically track attestations.  

RELATED CONTENT: What the National Cybersecurity Strategy means for software providers

“Solutions like the Tidelift open source data intelligence capabilities can be ideal for organizations seeking human-validated data on the secure software development practices used in open source projects, ” said Jim Mercer, research vice president of DevOps and DevSecOps at IDC. “These types of insights can equip organizations with detailed and validated first-party information about the secure software development practices used by the open source projects in their software supply chain that can help them strengthen their security posture and assist them with complying with emerging government compliance requirements.”

The post Tidelift introduces new intelligence capabilities for minimizing open-source risk appeared first on SD Times.

The report claims that only 11% of open-source projects are actually actively maintained. 

Despite these flaws, Sonatype still says that 96% of vulnerabilities are avoidable. There were 2.1 billion downloads of open-source software that had known vulnerabilities for which there was a newer version with the issue fixed. 

“A lot of maintainers are very diligent – Big Tech companies go out of their way to hire talented people to maintain libraries they rely on,” said Brian Fox, CTO at Sonatype. “Our industry needs to direct its efforts towards the right place. The fact that there’s been a fix for almost all downloads of components with a known vulnerability tells us an immediate focus should be supporting developers on becoming better decision-makers, and giving them access to the right tools. The goal is to help developers be more intentional about downloading open source software from projects with the most maintainers and the healthiest ecosystem of contributors. This will not only create safer software, but also recoup nearly two weeks of wasted developer time each year.”

The number of supply chain attacks continues to increase year-over-year. In 2023, there were twice as many attacks as the combined number from 2019-2022. This equates to 245,032 malicious packages, with one in eight open source downloads containing a known vulnerability. 

Sonatype also said they found a disconnect between how secure companies think they are versus the reality. 67% say they are confident they don’t have code from vulnerable libraries in their systems, but 10% have suffered a security breach due to vulnerabile components this year.

And finally, the company found that 39% of companies find a vulnerability within one to seven days, 29% take over a week, and 28% take less than one day.  

The post Sonatype shines light on current state of supply chain security in latest report appeared first on SD Times.

Now the U.S. federal Cybersecurity & Infrastructure Security Agency (CISA) is building on that work with a new roadmap specifically for securing open-source software (OSS). 

“CISA recognizes the immense benefits of open source software, which enables software developers to work at an accelerated pace and fosters significant innovation and collaboration. With these benefits in mind, this roadmap lays out how CISA will help enable the secure usage and development of OSS, both within and outside the federal government,” CISA wrote in the document for the roadmap. 

The roadmap defines two major types of open-source vulnerabilities. The first is the cascading effects of vulnerabilities for widely used open-source software. It cited Log4Shell as an example of the widespread consequences that could result from open-source software being compromised. 

The second is supply chain attacks on open-source repositories, which could result in negative downstream impacts, such as a developer’s account being compromised and an attacker using it to commit malicious code. 

The roadmap lists four key priorities: establishing its own role in supporting security of open source, driving visibility into usage and risks of open source, reducing risks to the federal government, and hardening the open-source ecosystem. 

According to CISA, this will all help it achieve its vision for open-source software, which is one in which “every critical OSS project is not only secure but sustainable and resilient, supported by a healthy, diverse, and vibrant community.”

Dan Lorenc, co-founder and CEO of supply chain security company Chainguard, feels that CISA has done a good job in segmenting the problems in this field and then prioritizing work to address them. 

He also said they did a good job at recognizing that the work needs to “happen upstream, and CISA employees will need to engage directly with communities,” though he said he still remains skeptical on how that will actually go, but is trying to stay optimistic. 

Lorenc recommends the government put some efforts into actually funding open-source projects, which the roadmap currently doesn’t address at all. 

“The government doesn’t have a great reputation for helping out with direct code or other contributions, but they do have the ability to help fund work already being done to achieve many of these roadmap items, such as memory safety, vulnerability remediation and SBOM tooling,” Lorenc told SD Times. “The government collaboration model here can’t be ‘you push, we’ll steer.”

The post CISA releases roadmap for securing open-source software appeared first on SD Times.

Cloud-native applications typically use a microservices architecture with a centralized infrastructure like a service mesh. These applications are often developed using DevSecOps, which uses CI/CD pipelines to guide software through stages like build, test, package, and deploy, akin to a software supply chain, according to the document.

“This breakdown is very helpful for development organizations, as it provides more concrete guidance on how to secure their environments and processes. One thing that stands out is the emphasis on the definition of roles and, closely related, the identification of granular authorizations for user and service accounts,” said Henrik Plate, security researcher at Endor Labs. “This is necessary to implement access controls for all activities and interactions in the context of CI/CD pipelines according to least-privilege and need-to-know principles. However, the management of all those authorizations across the numerous systems and services invoked during pipeline execution can be challenging.”

Recent analyses of software attacks and vulnerabilities have prompted governments and private-sector organizations in software development, deployment, and integration to prioritize the entire software development lifecycle (SDLC). 

The security of the software supply chain (SSC) relies on the integrity of stages like build, test, package, and deploy, and threats can emerge from malicious actors’ attack vectors as well as from defects introduced when proper diligence is not followed during the SDLC, according to the NIST draft.

“It’s not surprising that the document acknowledges that the ‘extensive set of steps needed for SSC security cannot be implemented all at once in the SDLC of all enterprises without a great deal of disruption to underlying business processes and operations costs,” Plate explained. 

This highlights the timeliness of providing guidance to organizations on implementing high-level recommendations like the Secure Software Development Framework (SSDF), which is a set of fundamental, sound, and secure software development practices based on established secure software development practice documents from organizations such as BSA, OWASP, and SAFECode, according to the NIST draft.

The NIST draft addresses the upcoming self-attestation requirement for software suppliers to declare adherence to SSDF secure development practices for federal agencies. The document aims to clarify expectations in the context of DevSecOps and CI/CD pipelines regarding what is considered necessary, according to Plate.

Plate added that one major concern with the draft is that tools that can improve the SSC like Sigstore and in-toto are not yet widely adopted with only a few open-source ecosystems including npm and select commercial services, having integrated it.

“It will require some time until those technologies are adopted more broadly in various open-source ecosystems and among open-source end users,” Plate added.

Organizations should go beyond simply detecting open-source software defects after they occur. They should also proactively manage open-source dependency risks by considering factors like code quality, project activity, and other risk indicators. A holistic approach to open-source risk management helps reduce both security and operational risks, as outlined in the Top 10 Open Source Dependency Risks, according to Plate. 

This new draft by NIST is intended for a broad group of practitioners in the software industry, including site reliability engineers, software engineers, project and product managers, and security architects and engineers. The public comment period is open through Oct. 13, 2023. See the publication details for a copy of the draft and instructions for submitting comments.

The post NIST publishes new draft framework for integrating supply chain security into CI/CD pipelines appeared first on SD Times.

This brings both the Notary Project and Notation Project to version 1.0.0. Notation is a sub-project that implements Notary specifications. 

Included in this release are an OCI signature specification, OCI COSE signature envelope, OCI JWS signature envelope, OCI signing and verification workflow, signing scheme, Trust Store, and Trust policy, and plugin specification for Notation. 

The team also revealed what it’s working on next. These include the ability to sign and verify arbitrary blogs, integration with GitHub Actions, a HashiCorp Vault plugin, plugin lifecycle management, timestamping support, and the ability to manage trust policies using CLI commands. 

“As containers and cloud native artifacts become common deployment units, users want to make sure that they are authentic in their environments. The Notary Project is a set of specifications and tools intended to provide cross-industry standards for securing software supply chains through signing and verification, signature portability, and key/certificate management,” the project maintainers wrote in a blog post.

The post CNCF’s Notary and Notation projects get major update appeared first on SD Times.