The visibility of security risk from software went through a sea of change last year when the president of the United States issued an executive order on cybersecurity that was inspired at least in part by prominent and damaging breaches, many due to insecurities in software used in critical infrastructure.
The executive order elevated the risks posed by immature software development and operations practices to a board-level agenda in most organizations and dramatically expanded the attention paid to these risks by most security teams. Application security could no longer be relegated to an issue for software development to solve. There is much more at stake given the sharp rise in strategic importance of software to every business. In this context, software risk is business risk.
The Rise Of Modern Software
While the business risk from software security has undoubtedly increased, it’s important to understand that the way this risk is managed has shifted. Fundamentally, there is way more software in every business, and the way that software is built has rapidly changed. The confluence of these factors leads to more complexity, and complexity breeds insecurity. Attackers thrive on the edge cases of the attack surface of a complex application.
For decades, the predominant way that new business applications were built was by a team of internal software developers tasked with designing and building the applications to meet the unique requirements of the business. Through the 1980s and ’90s, information technology became a much more strategic investment in most organizations, which coincided with the rise of the internet and everything that it made possible in terms of instant communication, rich customer experiences and data-driven insights. These expectations created competitive pressure to move faster and adopt new software technologies to stay ahead.
As a result, software changed from being written to being composed. In order to meet the time-to-market demands, modern applications evolved from a pile of internally written code to a composite of software components from multiple sources. Modern applications are now a combination of custom code, open-source software, third-party proprietary libraries and external APIs. This has created phenomenal velocity and innovation in software, but with this shift came new risks.
Research from several government and technology organizations suggests that this shifting landscape is continuing to result in significant security challenges. The Cybersecurity and Infrastructure Security Agency (CISA) of the Department of Homeland Security frequently issues warnings of the dangers of supply chain attacks and advanced persistent threats. My company’s Open Source Security and Risk Analysis report shows that while many organizations are making progress in controlling open-source risk, the severity and scope of the potential damage is increasing. The report also found the prevalence of old, outdated and vulnerable software that persists in live applications for years.
The news isn’t all bad though. The analysis shows that organizations that adopt open source risk management programs are getting better at controlling this risk. However, outdated libraries persist and supply chain attacks are becoming more targeted and severe.
How To Trust Your Software
These worsening risks inherent in modern applications necessitate a different approach to how you think about building software.
Since software is effectively constructed from raw materials brought together from many different sources, some organizations are beginning to approach the problem as more than a software development process. They began to view it as a supply chain. The software supply chain applies industrial and consumer production principles from traditional supply chain and risk management to rethink how to proactively manage software risk in a more disciplined and systematic way.
A software supply chain links all the libraries and decisions that affect software through its life cycle. Software supply chain risks threaten the functionality, reliability, safety and security of software, and can be introduced by internal or external sources. Software supply chain risk management (SSCRM) then coordinates efforts to identify, monitor, detect and mitigate threats to the software during its development, deployment or maintenance. It offers a consistent approach to apply to software you build, buy or download as open source.
To get started with this approach, there are simple questions to ask in your software supply chain: What’s in your software? Where did it come from? And can you trust it?
Within each of these areas, there are proven approaches to answering these questions. A systematic program for producing a software bill of materials (SBOM) provides transparency into all of the software that’s included in your applications. The SBOM approach, which is in the process of becoming a mandate for government software procurement based on the aforementioned executive order, is an important first step in understanding what is inside an organization’s software.
In a sense, the SBOM serves as an ingredient label for complex modern applications. After the software ingredients are known, you then have to perform analysis on each of the individual components and versions to collect a broad view of the riskiness of that combination.
This can be daunting when there are thousands of software component and version combinations, which is very typical in a medium-sized application. An automated process called software composition analysis (SCA) can help by identifying open-source software components and versions at scale and by providing instant visibility into the software SBOM and assigning risk ratings of all of the included software.
To get the full value of these automated SCA tools, the most successful organizations establish open-source security programs that build repeatable processes for educating development teams about open-source risk, systematically identifying the risk during the development process and remediating the associated risks before the software ships.
Finally, a set of practices and processes for proactively testing and securing software as it’s written, known as a secure software development life cycle, enables you to systematically build trust in your software. From a new understanding of how software risk has evolved, and by addressing these three simple questions, you’ll have a leg up on controlling the business risk from software.
Courtesy- https://www.forbes.com/sites/forbestechcouncil/2022/05/17/in-todays-world-software-risk-is-business-risk/?sh=454f863916f2