It’s Time to Bake Security into Software from the Start

One of the most unexpected consequences of ransomware attacks in 2021 may have been the nationwide cream cheese shortage caused by an attack on one of the nation’s largest cream cheese manufacturers. Though the attack only stopped production for a few days, the disruption was enough to leave bagel shops across the country — and New York’s iconic Junior’s Cheesecake — scrambling to secure the cream cheese they needed.

But while this attack grabbed headlines because of the immediate impact it had on our breakfast, we should be more worried about increased attacks in software supply chains. The consequences of such attacks can easily extend beyond a narrow sector like cheesemaking and interrupt large sections of the global economy.

Software supply chain attacks like the exploit of the zero-day vulnerability in Apache Log4j exposed thousands of enterprise and U.S. government customers to potential damages. The attack was compounded by uncertainty as many IT departments struggled to determine if their software products and systems were affected.

The lesson here is clear. It’s no longer enough for cybersecurity to be inserted at the end of the application development cycle. Instead, security needs to be baked into software development as early as possible.

Securing the Software Development Life Cycle

There is a key disconnect that underpins the challenge of completely embedding security in the software development life cycle — the differing priorities between developers and security teams. As more and more organizations become software developers themselves regardless of industry, and the leverage of multi-cloud and hybrid cloud environments continues to increase in complexity, developing with security in mind from the beginning is key. 

While the speed of development and security may not always go hand in hand, having the training, tools, and systems in place to take a security-first approach from the planning stages, companies can gradually close the gap between the speed of development and security. More importantly, organizations that embrace security from the beginning can avoid the massive financial and reputational damages that occur when key products or systems are compromised. The secure SDLC is relevant not just for software companies, but for any large corporation that is investing in proprietary software to automate their internal processes.

The interesting challenge about a secure SDLC is that there is no silver bullet or catch-all solution that organizations can adopt. It starts with strong training of—and awareness from— individual developers. Traditionally dev teams have been focused on hiring technically strong developers—be it those who are self-taught or have years of extensive school training. This, however, may not be synonymous with developers that can write ‘secure’ code. Hence, it is necessary to build a training system that teaches developers best practices and continuously updates them on the latest vulnerabilities to begin to have a culture of secure code development.

As the popularity of ‘shift left’ grows, we’ve seen boundless innovation in software solutions that help imbed security from the beginning. Given the pace that product categories are emerging within the SDLC, it is becoming key to develop a methodology for determining which tools will be leveraged at which points within the cycle to maximize results. While solutions like open source vulnerability scanning and static/dynamic application testing have become popular in the SDLC, there is still ample room to integrate more security and automation without affecting speed to market. Like in threat modeling, which has traditionally been a lengthy whiteboard session for dev teams. Ultimately, however, having a defined strategy of when and how to integrate third-party solutions is essential so that organizations don’t find themselves overloaded with tools.

Understanding the Software Supply Chain

In May of last year, President Biden’s executive order on cybersecurity included a requirement that any company providing tech solutions to the U.S. government must also deliver a full software bill of materials (SBOM). An SBOM represents a full record of the supply chain relationships between components used in building software products and systems. When a bug or attack like Log4j takes place, the SBOM makes it significantly easier for a company to understand whether their software has been affected.

When software developers consider the need to secure their entire supply chain, they must look at it from two angles. The first concerns the software products themselves and the need to confirm that every component meets rigorous security standards. The second definition of the supply chain concerns the organizations with which a company partners. While your tech stack may be well protected, how secure is the data that your company shares with your accounting firm, your corporate lawyers, or your IT consultants? Any modern enterprise’s data will flow through a chain of cooperating businesses, and that chain is only as secure as its weakest link.

Bad actors recognize that the largest and most lucrative corporate targets will likely have extensive security measures in place. However, smaller companies that are downstream in a larger corporation’s supply chain could offer an easier opportunity for these criminals to get their foot in the door. In many cases, the larger corporation isn’t aware of the weakness in their supply chain, and they only become aware of it when a bad actor exploits it to steal the corporation’s sensitive data.

Supply chain risk assessments are now an essential step for organizations to firm up their cybersecurity. Leading vendors like Black Kite allow companies to identify potential weaknesses in their digital supply chain and allocate resources to address critical threats. Following initial assessments, these organizations can then rely on automation to conduct continuous risk assessments by evaluating the risks of individual users.

Building the Right Culture

As organizations recognize the growing importance of security in the SDLC, they may need to bolster their team with security experts that can embed throughout the development process. This need for new talent could prove challenging during the current shortage of both developer and security candidates. Enterprises must take a multifaceted approach by providing necessary training to their existing developer and security teams while working to identify potential hires that can seamlessly adopt secure SDLC methodologies.

A secure SDLC requires fundamental, comprehensive changes to the ways in which companies think about and build software. Instead of finishing a product and then taking a retroactive look at how to add security, the secure SDLC makes it possible to bake in adequate protection for every byte. The results of a rigorous security program are never flashy, but they pay long-term dividends by protecting a software provider and its customers from outsized harm in the future.