In this Cybersecurity special report, John Siefert is joined by Acceleration Economy analysts and CISOs Frank Domizio, Rob Wood, and Chris Hughes. They discuss software composition analysis (SCA), what it means and why it matters. Additionally, they give insights into how SCA works, the use of automation, and how SCA gives an understanding of potential threats and vulnerabilities. Finally, they offer advice on how CISOs can approach SCA strategies with executive teams and board members.
Highlights
00:08 — John, Frank, Rob, and Chris discuss software composition analysis (SCA). Frank recently published a Cybersecurity Minute on the topic — John asks Frank to break down the concept and explain why it matters.
01:00 — Software composition analysis provides a look into the code that organizations run to understand potential threats and vulnerabilities. As code is being built, there are “libraries” that contain various functions in the code. Frank says this can get complex very quickly. Often, third parties are called in to write, build, or change code — software composition analysis helps make sense of any changes to code created by a third party.
02:29 — How much of this process is automated versus manual? “The move is to automation,” says Frank, since a manual process — which would take many humans at a full-time pace — can quickly get complex.
03:13 — Chris has published several reports on the software bill of materials (SBOM). John notes the similarities between SBOM and SCA, then asks Chris to provide more context.
03:36 — Chris agrees that SCA is valuable for teams to understand that most of the code written in modern applications is coming from a third party — using up to 75% of open-source software components. SBOM builds on top of the concept of SCA and allows organizations to see what third parties are using, make informed decisions, and communicate that information to a third party. Essentially, SBOM is a way to convey to software consumers what components are in the software, the existing risks, and considerations to make when engaging with the software.
04:29 — As a CEO, John can recount being on general availability (GA) deadlines for software that is being developed inside organizations. He asks Rob if applying SCA tools slow down the process of meeting such deadlines.
04:53 — Rob doesn’t think so — the push to give software developers feedback on the potential risks of what they’re building will make it faster and cheaper to remediate. If SCA is applied in the later stages of software development, more problems will arise. However, if software composition analysis is applied as soon as the software is built, it will be easier to address any issues that come into play.
06:47 — John confirms that applying SCA tools and managing them from the start of a development project could accelerate the process of meeting deadlines. When SCA tools are applied during the later stages of development, it could slow teams down because they are presented with potential threats and vulnerabilities they hadn’t caught before.
07:17 — Rob equates security debt — insecure configurations, insecure code patterns — to financial debt. All debt has to be repaid. Starting early and with a plan puts an individual in a much better position to start repaying that debt.
08:40 — In mid-market and enterprise companies as well as the public sector, there has been a pattern of budget tightening. How can CISOs approach SCA strategies with executive teams and board members?
09:18 — At some point, organizations will have to start addressing technical debt. Shortened software lifecycles suggest that organizations will catch software issues and threats later on. Software supply chain attacks are an area that is being focused on by malicious actors. Making strategic investments in tools and understanding the open-source software consumption footprint will put companies in a better position for securing their software, suggests Chris.
10:07 — Frank notes that “developers should be developing, security people should be doing security.” Having SCA tools extrapolates developers from having to handle security issues, allowing them to focus on writing good code with tools from which they receive valuable information. By implementing SCA tools, developers can focus on writing code and leave the security vulnerabilities to the security teams.
11:25 — John wonders if SCA tools help tighten the link between software developers and CISOs.
11:25 — Rob agrees; there have been movements from DevSecOps and DevOps that are developer-centric and security teams are starting to recognize the value of a product developer. The bridge between these two roles is strengthening due to the fast feedback loop that has been created as a result of the last 20 years of learning.
13:53 — John asks Chris to describe the security approaches of the Cybersecurity Top 10 companies. Developers including Endor Labs and Snyk “play exactly in the space” which allows developers to focus on their core competencies. These vendors alleviate the “cognitive burden” associated with security.
15:57 — Rob feels that SCA solutions are relevant and necessary for cybersecurity teams and agrees that the Top 10 companies have focused solutions that target particular parts of software supply chain risks. There is no “one size fits all” security solution — the context of the problem that is being addressed really matters.
19:07 — Frank agrees that organizations must identify their core needs and then go after the tools that will address those needs. Certain tools are more appropriate for an organization’s specific requirements. So, before diving in, it is important to identify the issues that need addressing.
20:06 — Everyone’s needs are different. Organizations should look to align their business strategy with the execution of new tools. Implementing software composition analysis tools earlier, rather than later, will better position companies to combat any issues that arise.
Want more cybersecurity insights? Visit the Cybersecurity channel:
