When it comes to technology, there’s no such thing as doing it all anymore. Monolithic systems were once desirable because they delivered a cohesive set of functions to improve performance; lower operational overhead and simplify security—but they no longer work for many modern businesses. Because the code is so tightly coupled and creates lots of dependencies, making changes can have unintended side effects, which means it takes a lot of time to develop, test and deploy new features. In other words, outdated technology makes it very difficult to innovate at today’s demanding pace.
Enter microservices, an architecture that structures applications as a collection of finely grained services and lightweight protocols. By modularizing development, microservices speed release cycles and enable continuous integration and continuous delivery (CI/CD). But it is still impossible to “do it all,” even in a microservices architecture. Using third-party services and APIs can further speed development, and there’s a growing marketplace of proprietary and open source tools and libraries available.
The Rise—and Risks—of Open Source
Open source software (OSS) has been around for decades, but after Eric S. Raymond published The Cathedral and the Bazaar in 1997, the market for OSS in the commercial software industry really started to take off. Since then, OSS has grown in popularity and is now used by all types of companies and applications, including commercial products. In fact, according to the “2018 Open Source Security and Risk Analysis” report published by the Synopsys Center for Open Source Research & Innovation, open source components were found in 96% of all applications, with an average 257 components for each one.
There are many advantages to using open source code: quality, support and even security. Because you have so many eyes and hands on a set of code to review and test it, problems will be identified and quickly remediated—though of course, this assumes a high level of participation within the programmer community for any given piece of OSS. Security, however, is also sometimes considered a drawback. The argument here is that a bad actor also has full access to the source code to seek and exploit various vulnerabilities.
Organizations need to be able to manage their OSS implementations. And because the use of OSS is so widespread, even organizations who don’t directly download and deploy open source code could still be using OSS that’s embedded in systems within their infrastructure. Gaining visibility into the open source components in your code base can be a huge challenge, with both security and compliance implications. As the Synopsys report states, “Unlike commercial software, where updates are automatically pushed to users, open source has a pull support model—users are responsible for keeping track of vulnerabilities, fixes and updates for the open source they use.”
The Role of Software Composition Analysis (SCA) in the Security Toolkit
This where software composition analysis (SCA) comes into play. SCA tools essentially take an inventory of your open source usage. Different SCA solutions provide different levels of information, which can include the OSS license, if there’s a vulnerability associated with that component, if multiple versions are present in an application, the age of the component, the precise location of a vulnerable component and more. Some tools can even be used in the selection process, identifying vulnerabilities before you ingest the code. SCA can also help with OSS legal compliance.
SCA plays an important role in application security, but you can’t just ingest SCA and call it a day. It’s important to understand how SCA fits into the overall security toolkit, and to orchestrate your vulnerability discovery and remediation program accordingly.
Application security testing is a must, and there are different types of xAST tools. Static application security testing (SAST) looks for vulnerabilities inside your code, while dynamic application security testing (DAST) identifies vulnerabilities that can only be detected by testing an application from the outside while it’s running, much like a hacker would. Interactive application security testing (IAST) provides in-application vulnerability analysis while the functionality is being run, which can be automated. Because IAST can uncover vulnerabilities quickly and early in the SLDC, it’s well-suited to CI/CD environments.
So, if you have IAST and SCA, you’ve got the security of both your own code and your OSS covered right? Unfortunately, it’s not that simple. They’re not two halves of the same whole, as is illustrated by this super helpful infographic on SAST vs. SCA that WhiteSource put together. SCA looks at an open source component on its own in isolation, whereas IAST tests the final application functionality which may use one or more open source components.
Application Security at the Speed of Digital Transformation
One of the primary goals of moving to a microservices architecture and adopting third-party and open source services is to dramatically increase development agility. Because security and compliance are a non-negotiable, it’s not enough to simply assemble a security toolkit to cover all your bases. You need to integrate those tools to work together and build them into the earliest stages of your development processes and systems, so vulnerabilities are caught as early in the SDLC as possible.
*** This is a Security Bloggers Network syndicated blog from Blog | ZeroNorth authored by ZeroNorth. Read the original post at: https://www.zeronorth.io/blog/can-your-sca-really-secure-all-your-applications/