The survey, Anchore’s 2024 Software Supply Chain Security Report, also found that less than half of respondents are following supply chain best practices like creating software bill-of-materials (SBOMs) for the software they develop (49% of respondents) or for open source projects they use (45%) of respondents. Additionally, only 41% of respondents request SBOMs from the third-party vendors they use. Despite these low numbers, this is a significant improvement from 2022’s survey, when less than a third of respondents were following these practices. 

The report found that 78% of respondents are planning on increasing their use of SBOMs in the next 18 months, and 32% of them plan to significantly increase use. 

“The SBOM is now a critical component of software supply chain security. An SBOM provides visibility into software ingredients and is a foundation for understanding software vulnerabilities and risks,” Anchore wrote in the report.

The report also found that currently 76% of respondents are prioritizing software supply chain security.

Many companies are having to make this a priority as part of their efforts to comply with regulations. According to the report, organizations are now having to comply with an average of 4.9 regulations and standards, putting more pressure on them to get security right. 

Of the companies surveyed, more than half have a cross-functional (51%) or fully dedicated team (8%) that works on supply chain security. 

Finally, 77% of respondents are worried about how embedded AI libraries will impact their software supply chain security.  

For the survey, Anchore interviewed 106 leaders and practitioners that are involved in software supply chain security at their company.

The post Report: Only 1 in 5 organizations have full visibility into their software supply chain appeared first on SD Times.

This new free tool automates the process of creating SBOMs. Developers give the SBOM Manager access to their code repositories and it will create an SBOM that includes inventories of components, vulnerabilities, and licenses. Alternatively, they can import an existing SBOM file to speed up the process. 

Once created, owners can edit the details, add custom metadata, and catalog components so that they can be used across different SBOM. 

They can also define custom licenses and manage open source license risks, obsolescence, and copyrights. 

The created SBOMs can be exported into various formats including Excel, Word, PPT, and CycloneDX. 

The platform also includes an interactive dashboard that provides at-a-glance insights of component categories, vulnerabilities, and licenses. 

“The product leverages advanced software intelligence to provide an automated, customizable, and user-friendly approach to SBOM management,” said Greg Rivera, vice president of CAST. “This product is intended for organizations that need to generate and maintain accurate SBOMs without the complexity and high costs associated with traditional solutions.”

You may also like…

Companies still need to work on security fundamentals to win in the supply chain security fight

The post CAST simplifies SBOM creation with new free tool appeared first on SD Times.

Yes, tooling is important; You can’t secure the software supply chain with secure coding practices alone. But you’ll need to combine those best practices with things like software bills of materials (SBOMs), software composition analysis, exploit prediction scoring systems (EPSS), and more.  

Before we can begin to think about what tooling can help, step one in this fight is to get the fundamentals down, explained Rob Cuddy, global application security evangelist at HCLSoftware. “There’s a lot of places now that are wanting to do security better, but they want to jump to steps four, five, and six, and they forget about steps one, two, and three,” he said. 

See also: A guide to supply chain security tools

He explained that even with new types of threats and vulnerabilities that are emerging, it’s still important to take a step back and make sure your security foundation is strong before you start getting into advanced tooling. 

“Having the basics done really, really well gets you a long way towards being safe in that space,” he said. 

According to Janet Worthington, senior analyst at Forrester, the first step is to ask if you’re following secure development practices when actually writing software.

“Are we secure by design when we’re building these applications? Are we doing threat modeling? Are we thinking about where this is going to be installed? About how people are going to use it? What are some of the attack vectors that we have to worry about?” 

These are some of the basics that companies need to get down before they even start looking at where tooling can help. But of course, tooling does still play a crucial role in the fight, once those pieces are in place, and Cuddy believes it is crucial that any tool you use supports the fundamentals.

The bare minimum for software supply chain security is to have an SBOM, which is a list of all of the components in an application. But an SBOM is just an ingredient list, and doesn’t provide information about those ingredients or where they came from, Worthington explained. 

Kristofer Duer, software architect team lead at HCLSoftware, added, “you need to know what goes into it, but you also need to know where it’s built and who has access to the code and a whole list of things.”

According to Worthington, this is where things like software composition analysis tools come in, which can analyze SBOMs for security risks, license compliance issues, and the operational risk of using a component. 

“An example of an operational risk would be this component is only maintained by one person, and that single contributor might just abandon the software or they might go do something else and no longer be maintaining that application,” she said. 

According to Colin Bell, AppScan CTO at HCLSoftware, EPSS — a measure of the likelihood that a vulnerability actually gets exploited — is another emerging tool to improve supply chain security by smartly prioritizing remediation efforts.

“Just because you have something in your supply chain doesn’t necessarily mean that it’s being used,” he explained. 

Bell said that he believes a lot of organizations struggle with the fact that they perceive every vulnerability to be a risk. But in reality, some vulnerabilities might never be exploited and he thinks companies are starting to recognize that, especially some of the larger ones. 

By focusing first on fixing the vulnerabilities that are most at risk of getting exploited, developers and security teams can effectively prioritize their remediation strategy. 

Worthington added that integrating secure by design foundations with some of these tools can also cut down on release delays that are caused by scanning tools finding security issues at the last moment, right before deployment, which might prevent deployments from going out until the issues are resolved. This is needed as companies are under more and more pressure to release software faster than ever. 

“Organizations that release frequently with high confidence do so by embedding security early in the Software Development Life Cycle (SDLC),” said Worthington. “Automating security testing, such as Software Composition Analysis and Static Application Security Testing, provides feedback to developers while they are writing code in the IDE or when they receive code review comments on a pull request. This approach gives developers the opportunity to review and respond to security findings in the flow of work.”

She also said that identifying issues before they are added to the codebase can actually save time in the long run by preventing things from needing to be reworked. “Security testing tools that automate the remediation process improve product velocity by allowing developers to focus on writing business logic without having to become security experts,” she said. 

XZ Utils backdoor highlights importance of people in protecting the software supply chain

However, as mentioned at the top, tools are only one component in the fight, and secure practices are also needed to deal with more advanced threats. A recent example of where the above-mentioned tools wouldn’t have done much to help on their own is when in March, it was announced that a backdoor had been introduced into the open-source Linux tool XZ Utils. 

The person who had placed the backdoor had been contributing to the project for three years while gaining the trust of the maintainers and ultimately was able to rise to a level at which they could sign off on releases and introduce the backdoor in an official release. If it hadn’t been detected when it was and had been adopted by more people, attackers could have gained access to SSH sessions around the world and really caused some damage. 

According to Duer, the vulnerability didn’t even show up in code changes because the attacker put the backdoor in a .gitignore file. “When you downloaded the source to do a build locally, that’s when the attack actually got realized,” he said.

He went on to explain that this goes to show that developers can no longer just “get the source and run a build and call it a day. You have to do so much more than that … They have the SHA-256 hash mark on the bins, but how many people run those commands to see if the thing that they downloaded is that hash? Does anybody look in the CVE for this particular package to see if there’s a problem? Where do you rely on scanners to do that work for you? It’s interesting because a lot of the problems could be avoided with another couple of extra steps. It doesn’t even take that much time. You just have to do them,” Duer said. 

Worthington added that it’s really important that the people actually pulling components into their applications are able to assess quality before bringing something into their system or application. Is this something maintained by the Linux Foundation with a vibrant community behind it or is it a simple piece of code where nobody is maintaining it and it might reach end of life? 

“A very sophisticated attacker played the long game with a maintainer and basically wore that poor maintainer down through social engineering to get their updates into XZ Utils. I think we’re finding that you need to have a really robust community. And so I think SBOM is only going to get you so far,” said Worthington.

While this may seem like an extreme example, the Open Source Security Foundation (OpenSSF) and the OpenJS Foundation put out an alert following the incident and implied that it might not be an isolated incident, citing similar suspicious patterns in two other popular JavaScript projects. 

In the post, they gave tips for recognizing social engineering attacks in open source projects, such as:

• Aggressive, but friendly, pursuit of maintainers by unknown community members
• Requests from new community members to be elevated to maintainer status
• Endorsement of new community members coming from other unknown members
• PRs containing blobs as artifacts
• Intentionally difficult to understand source code
• Gradually escalating security issues
• Deviation from typical project compile, build, and deployment practices
• A false sense of urgency to get a maintainer to bypass reviews or controls

AI will make things worse and better

AI will also exacerbate the number of threats that people have to deal with because as much as AI can add useful features to security tools to help security teams be more effective, AI also helps the attackers. 

Having AI in applications complicates the software supply chain, Worthington explained. “There’s a whole ecosystem around it,” she said. “What about all the APIs that are calling the LLMs? Now you have to worry about API security. And there’s gonna be a bunch of new types of development tools in order to build these applications and in order to deploy these applications.”

Worthington says that attackers are going to recognize that this is an area that people haven’t really wrapped their heads around in terms of how to secure it, and they’re going to exploit that, and that’s what worries her most about the advances in AI as it relates to supply chain security. 

However, it’s not all bad; in many ways, supply chain security can benefit from AI assistance. For instance, there are now software composition analysis tools that are using generative AI to explain vulnerabilities to developers and offer recommendations on how to fix it, Worthington explained. 

“I think AI will help the attackers but I think the first wave is actually helping defenders at this point,” she said. 

Bell was in agreement, adding “if you’re defending, it’s going to improve the threat detection, it’s going to help with incident response, and it’s going to help with detecting whether vulnerabilities are real.”

The government is starting to play a role in securing supply chains

In 2021, President Biden signed an executive order addressing the need to have stronger software supply chain security in government. In it, Biden explained that bold change is needed over incremental improvements, and stated that this would be a top priority for the administration. 

The executive order requires that any company selling software to the government provide an SBOM and set up a pilot program to create an “energy star” type program for software so that the government can easily see if software was developed securely. 

“Too much of our software, including critical software, is shipped with significant vulnerabilities that our adversaries exploit,” the White House explained. “This is a long-standing, well-known problem, but for too long we have kicked the can down the road. We need to use the purchasing power of the Federal Government to drive the market to build security into all software from the ground up.” 

Worthington said: “I think the Biden administration has done a really good job of trying to help software suppliers understand sort of like what the minimum requirements they’re going to be held to are, and I think those are probably the best place to start.”

Cuddy agreed and added that the industry is starting to catch up to the requirements. “Not only do you need to generate a bill of materials, but you have to be able to validate across it, you have to prove that you’ve been testing against it, that you’ve authorized those components … So much of it started with the executive order that was issued a few years ago from President Biden, and you’ve now seen the commercial side starting to catch up with some of those things, and really demanding it more,” he said.

The post Companies still need to work on security fundamentals to win in the supply chain security fight appeared first on SD Times.

Sounds like what companies do when reaching out to customers about new rollouts, right? Well, it is, when you consider your development team as being customers of the platform.

“Treat your developers, treat your DevOps teams, as your own internal customer and interview them,” urged Bill Manning, Solution Engineering Manager at JFrog, which offers a Software Supply Chain platform to speed the secure delivery of new applications and features. Once you’ve listened to the developers, Manning went on, you can roll their feedback into defining your platform engineering approach, which helps organizations find ways to be more efficient, and to create more value by streamlining development. 

The reason platform engineering is becoming increasingly important is that over time the process of designing and delivering software has become more complex, requiring a number of different tools and customizations, according to Sean Pratt, product marketing manager at JFrog. “When that happens,” he said, “You lack repeatable processes that can be tracked and measured over time.” 

Standardization and intelligent consolidation of tool sets, which can reduce the time, effort and cost needed to manage the sprawl many organizations face, is but one of the core tenets of platform engineering that JFrog talks about. ​​Among the others are reduction of cognitive load, reduction of repetitive tasks through automation, reusable components and tools, repeatable processes, and the idea of developer self-service.

Organizations using DevOps practices have seen the benefits of bringing developers and operations together, to get new features released faster through the implementation of smaller cycles, microservices, GitOps and the cloud. The downside? Coders have now found themselves smack-dab in the middle of operations. 

“The complexity [of software] has increased, and even though the tool sets in a way were supposed to simplify, they’ve actually increased it,” Manning said. “A lot of developers are suffering from cognitive overload, saying, ‘Look, I’m a coder. I signed up to build stuff.’ Now they have to go in and figure out how they are going to deploy [and] what is going to be running inside the container. These are things a lot of developers didn’t sign up for.”

Platform engineering has grown out of the need to address the burden organizations have placed on their development teams. By shifting left more practices with which developers are unfamiliar, there’s more responsibility on today’s developers to do more than just design elegant applications.

This all takes a toll on developers. Automating things like Terraform to provision infrastructure, or Helm charts for Kubernetes, for example, frees up developers to do what they do best – innovate and create new features at the pace the business needs to achieve. A developer would rather get a notification that a particular task is done rather than having to dive in and do it manually. 

While platform engineering can help standardize on tools, organizations still want to offer developers flexibility. “In a microservice world, for example, certain teams might need to use certain tools to get their job done. One might need to use Java with Jenkins for one project, while another team uses Rust with JFrog Pipelines to execute another project,” Pratt said. “So there’s a need for a solution that can bring all those pieces together under one umbrella, which is something JFrog does to help put consistent processes and practices in place across teams.” 

To be sure, a mentality shift is required for successful platform engineering.  “You know what, maybe we don’t need 25 tools. Maybe we can get away with five. And we might have to make some compromises, but that’s okay. Because the thing is, it’s actually beneficial in the long term.” Regardless of how many tools you settle on, Manning had a final piece of advice, “Think about how you bring them all together; that’s where universal and integrated platforms can help connect the disparate tools you need.”  

Content provided by SD Times and JFrog.

The post Platform engineering brings consistency to tools, processes under one umbrella appeared first on SD Times.