It’s reasonable to think about today’s software development environment as a bowl of alphabet soup. There’s homegrown proprietary software (PS), open-source software (OSS) and third-party or commercial off-the-shelf software (COTS) to deal with.
Yet, tucked away among all the acronyms and chunks of code lies a basic truth: it’s tough to know where all the code came from and if it is secure. The task isn’t made any easier by code sourced from business partners, vendors, contractors and others.
At this point, most organizations have already turned to some form of application security testing (AST) to handle their proprietary code and open source – more alphabet soup! Yet, as with all things digital, new security challenges arise daily. Just when you thought you had it taken care of, more vulnerabilities are popping up in third-party code. How can you keep on top of this growing challenge?
Getting with the Program
Today, the sheer amount of software found within a typical enterprise is nothing less than astounding—programs can number in the hundreds to thousands. As organizations build alliances, use APIs, construct IoT frameworks and share code and data, the complexities only grow.
Let’s take a look at how you can mind your Ps and Qs (pointers and queues!) and follow the ABCs of best practices in application security.
Assess your code factory. It’s important to think broadly and holistically about code. This means understanding what works best in particular situations. It may be establishing a shift left methodology, which empowers developers to have a security-first stance that closely aligns with their development methods, developer personas and workflows. It may revolve around the composition of the components used to construct your code. How much is in-house code or a COTS product? Also, determine how much risk is acceptable to you. Variables are numerous, but this assessment should include who uses the software (e.g., internal user vs. external customers), the data accessed from the program, the number of users, etc.
Bring static code analysis into the picture for all developers, not just the QA team. The foundation of any application security framework is static application security testing (SAST). It spots flaws that can lead to issues such as Use of Tainted Data, Path Traversal, Buffer Overflows and Use of Dangerous Functions as developers write and test code. SAST examines code at a source and even a binary level and alerts teams when it finds a new vulnerability. The most advanced SAST tools are integrated into development processes and systems—and are required if developers are going to embrace creating more secure code.
Create a software composition analysis (SCA) strategy to deal with open source and third-party code. Forester found that 43% of organizations plan to use SCA within the next year. This is an encouraging trend. However, it’s important to understand that most SCA applications, while valuable, can’t spot every code problem. Traditional SCA is valuable for scanning open-source code, but it can’t peer into third-party code to discover known vulnerabilities. This requires SCA technology to provide visibility down to a binary level across code libraries and repositories to create a software bill of materials (SBOM).
Binary SCA (BSCA) allows you to extend your protection. Today, there’s often no way to know how libraries and components were assembled and that they are secure. This is where scanning techniques like BSCA shine. It can see beyond the flat earth of conventional code scans to spot vulnerabilities that would otherwise go undetected.
When organizations deploy a comprehensive framework of application security tools and match them to their specific needs, it’s possible to examine software and code in broader and deeper ways. This includes BSCA, which should be a pillar of any modern application security toolkit. With the right strategy, it’s possible to transform a bowl of application security alphabet soup into an approach that spells s-u-c-c-e-s-s.
