Finding, prioritizing, and fixing vulnerabilities during Development and protecting the applications from attacks in Production is the security best-practice. Yet, this is ineffective, resource intensive and exacerbated as organizations modernize their development practices. This blog provides the blueprint for a purpose-built approach to make our applications more secure.
Let’s look at how we can measure the risk of an application (Figure-1).
The risk and effort required in each stage can be summarized as follows:
As the good guys, we have to go through this process, which can take months. The bad guys have to the advantage because they only need one vulnerability. The deck is clearly stacked against us. It doesn’t have to be this way.
Proposing a new approach
What can we envision to be the requirements of a solution that can flip this problem to create a more level playing field?
- Integrate code analysis (static, dynamic) that is as agile as the application development process. It would provide results within minutes of a new software release.
- Conduct software composition analysis (SCA) that is as agile as the application development process. As an example, a security team at a large bank recently ran a legacy SCA tool on a few of their applications. The tool identified more than 300 vulnerable components causing the security team to question whether they should ask the developers to look at each component. Instead, what we need is a solution that (a) identifies the components, (b) identifies vulnerabilities, if any, in each component, (c ) identifies whether the vulnerability manifests in the application based on the usage of the library, and (d) identifies the line of code where the vulnerability lies. This approach, unlike a legacy SCA tool, can empower security to deliver the specifics/accuracy engineering teams need to significantly shorten their investigate/fix cycles.
- Once all the vulnerabilities are identified across your custom code, 3rd party libraries and frameworks, the next step is patching. It would be a great day for security if vulnerabilities got the first priority, but that is seldom the case. The priorities are driven by business needs (Customer demands, need to outwit the competition, etc.). So it would be ideal if we could get protection for the vulnerability until engineering could fix it, like a virtual patch.
If all of this was wrapped up in one solution (Figure-2), this is how security would get integrated into agile development methodology (DevOps):
- For each software release, vulnerabilities are identified in development. This would include both known and unknown vulnerabilities. It would cover all the components of your application (custom code, open source libraries, 3rd party APIs, etc.) to map the application’s attack surface.
- In production, an agent would protect the software from its attack surface. This would buy the engineering team time to fix the vulnerabilities as well as being extremely accurate and performant.
If you would like to be a part of such a world where you are helping engineering move faster and enabling business priorities, try ShiftLeft. It’s not difficult. All you need is an application to try this out with and as little as 3 days to see how the solution works.
*** This is a Security Bloggers Network syndicated blog from ShiftLeft Blog - Medium authored by Manish Gupta. Read the original post at: https://blog.shiftleft.io/can-security-be-a-business-enabler-1446dc9198ed?source=rss----86a4f941c7da---4