{"id":55119,"date":"2024-07-08T14:00:00","date_gmt":"2024-07-08T18:00:00","guid":{"rendered":"https:\/\/sdtimes.com\/?p=55119"},"modified":"2024-07-10T15:07:33","modified_gmt":"2024-07-10T19:07:33","slug":"companies-still-need-to-work-on-security-fundamentals-to-win-in-the-supply-chain-security-fight","status":"publish","type":"post","link":"https:\/\/sdtimes.com\/security\/companies-still-need-to-work-on-security-fundamentals-to-win-in-the-supply-chain-security-fight\/","title":{"rendered":"Companies still need to work on security fundamentals to win in the supply chain security fight"},"content":{"rendered":"

Though this is technically a \u201c<\/span>Buyer’s Guide<\/span><\/a>\u201d by SD Times terminology, let\u2019s preface this article by remembering that buying a piece of software isn\u2019t the key to fixing all security issues. If there was some magical security solution that could be installed to instantly fix all security problems, we wouldn\u2019t be seeing a year-over-year increase in supply chain attacks, and you probably wouldn\u2019t be reading this article.<\/span><\/p>\n

Yes, tooling is important; You can\u2019t secure the software supply chain with secure coding practices alone. But you\u2019ll need to combine those best practices with things like software bills of materials (SBOMs), software composition analysis, exploit prediction scoring systems (EPSS), and more.\u00a0\u00a0<\/span><\/p>\n

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 <\/span>HCLSoftware<\/span><\/a>. \u201cThere’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,\u201d he said.\u00a0<\/span><\/p>\n

See also: A guide to supply chain security tools<\/a><\/strong><\/p>\n

He explained that even with new types of threats and vulnerabilities that are emerging, it\u2019s still important to take a step back and make sure your security foundation is strong before you start getting into advanced tooling.\u00a0<\/span><\/p>\n

\u201cHaving the basics done really, really well gets you a long way towards being safe in that space,\u201d he said.\u00a0<\/span><\/p>\n

According to Janet Worthington, senior analyst at <\/span>Forrester<\/span><\/a>, the first step is to ask if you\u2019re following secure development practices when actually writing software.<\/span><\/p>\n

\u201cAre 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?\u201d\u00a0<\/span><\/p>\n

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.<\/span><\/p>\n

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\u2019t provide information about those ingredients or where they came from, Worthington explained.\u00a0<\/span><\/p>\n

Kristofer Duer, software architect team lead at HCLSoftware, added, \u201cyou 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.\u201d<\/span><\/p>\n

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.\u00a0<\/span><\/p>\n

\u201cAn 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,\u201d she said.\u00a0<\/span><\/p>\n

According to Colin Bell, AppScan CTO at HCLSoftware, EPSS \u2014 a measure of the likelihood that a vulnerability actually gets exploited \u2014 is another emerging tool to improve supply chain security by smartly prioritizing remediation efforts.<\/span><\/p>\n

\u201cJust because you have something in your supply chain doesn’t necessarily mean that it’s being used,\u201d he explained.\u00a0<\/span><\/p>\n

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.\u00a0<\/span><\/p>\n

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.\u00a0<\/span><\/p>\n

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.\u00a0<\/span><\/p>\n

\u201cOrganizations that release frequently with high confidence do so by embedding security early in the Software Development Life Cycle (SDLC),\u201d said Worthington. \u201cAutomating 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.\u201d<\/span><\/p>\n

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. \u201cSecurity 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,\u201d she said.\u00a0<\/span><\/p>\n

XZ Utils backdoor highlights importance of people in protecting the software supply chain<\/b><\/h5>\n

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\u2019t 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 <\/span>XZ Utils<\/span><\/a>.\u00a0<\/span><\/p>\n

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\u2019t 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.\u00a0<\/span><\/p>\n

According to Duer, the vulnerability didn\u2019t even show up in code changes because the attacker put the backdoor in a .gitignore file. \u201cWhen you downloaded the source to do a build locally, that’s when the attack actually got realized,\u201d he said.<\/span><\/p>\n

He went on to explain that this goes to show that developers can no longer just \u201cget the source and run a build and call it a day. You have to do so much more than that \u2026 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,\u201d Duer said.\u00a0<\/span><\/p>\n

Worthington added that it\u2019s 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?\u00a0<\/span><\/p>\n

\u201cA 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,\u201d said Worthington.<\/span><\/p>\n

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

In the post, they gave tips for recognizing social engineering attacks in open source projects, such as:<\/span><\/p>\n