With DevSecOps on the rise, security efforts become developer-driven instead of an afterthought you would think of after deploying an application to production. Shifting security left becomes the norm. Before this is a reality in organizations, there are a number of challenges to overcome. In this article we will explore challenges and solutions to shift application security left as well as proposed trends and solutions that will see the light in the upcoming period.
Balancing speed of delivery and security
Developers in DevSecOps teams face enormous pressure to deliver great software as well as keep those applications secure at all times. Since the frequency and variety of deployments increases with the help of CI/CD pipelines, new vulnerabilities might pop up every now and then.
With the fast amount of changes, the security tools need to keep up with the constant changing landscape of infrastructure components as well as application versions. It’s about various stages in the Software Development Life-Cycle. Applications which are currently being developed and tested. Furthermore, think of applications which already running in production.
There is not enough time to constantly scan every environment for new vulnerabilities and security weaknesses. Besides this, there is even less time to analyze and judge every single vulnerability. Application security testing which relies on production testing and large-scale code scanning projects pose a threat to the speed and quality of delivery.
New solutions to this problem need to find an answer that helps the business stay fast and secure at the same time.
Becoming more proactive
Security efforts need to become proactive instead of reactive when it comes to detecting, preventing and mitigation of security issues. Not only from an infrastructure security perspective, but from an application security perspective as well. An developer-driven approach is crucial to ensure you adhere to “continuous security” in your organization.
Based on this philosophy, your developers become security champions and your organization benefits since the risks of deploying bad code to production decreases significantly. In addition to that, it’s much cheaper to fix an issue earlier on in the SDLC compared to when you discover it in production.
This brings us to an interesting topic: application security tooling will be more and more embedded into the DevOps tool chain. Partly because of the shift-left movement but also because they are much more developer friendly. Dedicated security teams which previously hold the power of tool selection and tool maintenance gets less influence of it. It leads to a clear shift of governance related challenges over these tools:
- Who will select the appropriate tools, the security teams which hold the best security experts or the developer teams which have the most accurate domain related knowledge? This knowledge is tight to application (functionality) which is crucial to understand the needs of the business.
- How to arrange the functional and technical maintenance of the tools if this decentralized approach is chosen?
- What about visibility of the “bigger picture” to identity trends and common threats across multiple developer teams?
- Think of the quality of the application security tools which run in the CI/CD pipelines compared to the dedicated tools of the security teams.
Becoming proactive instead of reactive when it comes to security issues is key here.
Dynamic testing in the CI/CD pipeline
SAST is all about scanning and analyzing “static source code”. What about DAST – which focuses primarily on the detection of vulnerabilities and other weaknesses of dynamic/running applications. Often DAST scanning is conducted when an application has already been deployed. If the results are below a certain threshold, you need to rollback to a previous version.
Now, DAST also becomes part of the CI/CD pipeline. Integrate SAST as well as DAST into the CI/CD pipeline gives organizations a more complete view of the intended deployments. Both from an IaC perspective as well as an application perspective. Sometimes, a successful attack requires combined information based on a weak application residing on a brittle piece of infrastructure. From this perspective, it make sense to have the scanning results combined and as early as possible.
Once SAST and DAST are combined and shifted towards the pre-deployment phase, think of the new buzzword called IAST (Interactive Application Security Testing). Yet another trend to follow. It’s about the complete picture. Scanning in isolated is too limited.
Add FAST to your CI/CD pipeline
FAST stands for Functional Application Security Testing. Functional tests tend to be slow to run and painful to set-up especially when it comes to serverless based applications that are composed of numerous components. In the future, FAST might (or will be) using DAST to integrate functional security testing into DAST. Combing both tests helps to speed up and provide a complete security related overview of the application component which is currently being developed.
Hacker level insight
Another interesting trend we see when it comes to DAST is the Hacker Level Insight. When it comes to PEN testing, you need to think and act like an attacker. The same is true for DAST. In the coming period, security experts expect DAST to become much more intelligent which evolves from a “simple vulnerability detection technique” towards a more comprehensive risk assessment tool that integrates data and insights which hackers use to target your system. It might be a bit early to state that we can now forget manual PEN tests but for sure this new movement will be very beneficial for Blue teams defending their systems.
Beyond alert fatigue: aggregation vulnerability information
Large enterprises which employ dozens of DevOps teams need to find a way to deal with all of the vulnerabilities that end up in their security tools. It’s not enough to just report anything and everything that has a certain criticality. Who-ever analyzes and decides about it needs to have at least the following meta-data at hand:
- Criticality of the issue (in relation to the importantness of the application)
- Application and/or DevOps team to which the finding belongs
- CIA rating of the application
- Other occurrences and remediation of the finding.
Let’s zoom in to the last bullet point: without knowing of other occurrences of the finding and how teams have solved it, you risk spending too much time on the fix. Or you do it wrong and make things worse. Perhaps it’s not so important as it might look like at first glance. And even if you decide to fix it, you need to test and verify the fix. A use case from another team greatly helps to implement the proposed solution. Collaboration between teams is essential without distracting them from doing the work they are responsible for.
Aggregation of vulnerabilities becomes a key aspect which security vendors need to take into account as well as tagging those. Both features help large organizations pinpoint their efforts and to remain flexible taking into account the challenge on how to deal with all of the findings.
APIs need to be secured as well
Connecting application (components) with each other and other external tools becomes more important than ever. Fixed and static connections become a thing of the past. API first is a common development approach for a lot of companies now. This brings new challenges such as:
- Developers and managers need to understand the security risks that arise when this becomes more common.
- The attack surface of API first applications is much broader compared to a N-tier application(stack). Security teams need to help developers secure their APIs.
- SAST and DAST tools also need to support API security best practices, and those APIs need to be scanned every time the CI/CD pipeline runs. Consider a micro-services application that comprises of several small components which are only accessible through their APIs. Your pipelines need to be fast and reliable as well as know about each other if there are interrelated dependencies.
For more information, check out the article about API security.
Susceptibility analysis with a clear focus
Open source software becomes more popular every day. Nearly every organization uses open source libraries and frameworks. It’s easy to integrate and include open source components in your applications. Checks to verify and automatically upgrade your open source dependencies (for example through Gradle or NuGet) are of great help. However, with this rising trend in mind, you risk security incidents which are quickly out of your control.
This is where susceptibility analysis comes into play. It helps to quickly find and detect vulnerabilities that matter in your software (components). In order to do so, it needs to scan existing and potentially future used libraries that might be harmful.
Nexus Lifecycle from Sonatype has a wonderful feature that shows every version of a library in a timeline. Past versions are shown but also future versions (if you happen to use an older version). It includes information about whether or not a vulnerability exists in any version so you can quickly decide whether or not to upgrade to a later version.
Continuous application security
Every challenge and solution presented here helps to strengthen the trend which is called “continuous application security”. To further enhance this topic, keep in mind that your organization remains responsible for data security at all times, whether you are running in the public cloud or on-prem.
It’s not enough to just scan your Infrastructure as Code templates. Beyond that, you need to identify improperly configured variables or missing ones in cloud resources you intend to deploy. You also need to scan for problematic issues in your data flows, structural controls and cloud misconfigurations. Rule packs which are dedicated to specific cloud services help to categories misconfigurations and vulnerabilities.
All help to ensure you practice continuous security and bring cloud security to the next level.
Shifting security left quickly becomes the norm in organization who take DevSecOps seriously. As always, it’s easier said than done. In this article I highlighted several challenges and their (proposed) solutions which help you actually implement it in your organization. Developers, security experts as well as managers need to work together to make this a reality. I hope this article helped you to push your security efforts forward.