Pragmatic Application Security - The SonarSource Way
Editor's Note: Updated March 2019 to reflect additional language coverage
Our goal at SonarSource is making it possible for developers everywhere to deliver clean, quality code. Specifically, we mean minimizing bugs, code smells and vulnerabilities. If we single out vulnerabilities, it can be tough to stay ahead of the curve and security efforts can seem like an escalating game of Whack-a-Mole. We feel your pain and we think there is an effective way to develop more secure applications.
Why Do We Care About Application Security?
With all the threats lurking out in the wild, application security remains a top-of-mind subject. In spite of these concerns, the number of security breaches continues to rise along with the number of compromised accounts containing user data. Why is this happening even with all the emphasis on better security? The simple answer is that it’s not easy! The challenge is improving security without disrupting your existing CI pipeline or slowing down your delivery velocity. Reducing vulnerabilities in your applications takes dedication, persistence and an effective game plan.
There are endless articles on this subject so how is this conversation different and why are we talking to you about this now? We simply think that the development community has matured and we’ve reached an important milestone in how to approach the problem. At SonarSource, we advocate a pragmatic approach involving Security Hotspot detection. Hotspots are security-sensitive pieces of code through which a vulnerability can flow. They require assessment by someone wearing a security hat to determine if they’re true vulnerabilities.
Security Hotspot detection in SonarQube v7.4
How Security Hotspots Can Help
Security Hotspots contrast with known vulnerabilities such as injection flaws. Security Hotspots can be just as ‘dangerous’, but require a dedicated review to determine if they pose a problem. Think of hotspot detection the same as shining a flashlight in areas of concern so you can investigate properly. Without hotspot detection, your development team could spend weeks browsing code not knowing where to focus their energy.
If we treat the problem by detecting known vulnerabilities and also flagging hotspots as potential vulnerabilities, then a path to better security becomes clear. Known vulnerabilities are the responsibility of the development team to correct. Security hotspots get picked up by an individual or team that is wholly or partially dedicated to reviewing them and then confirmed vulnerabilities cycle back to the development team. When you start fixing Security Vulnerabilities and reviewing Security Hotspots, you’re creating a Secure Software Development LifeCycle (SSDLC) process.
In practice, this approach has several benefits:
- You can stick with it over time
- Your existing development workflow doesn’t require major disruption
- It won’t break the bank
The payoff of a SSDLC approach is saving considerable time and money by catching issues earlier in the process.
Fitting Into the AppSec Bigger Picture
Let’s step back for a moment and talk about why a pragmatic approach makes sense. A key element is that complementary techniques are required to achieve comprehensive coverage and ultimately more secure code. At a high level, AppSec can be broken down into SAST, DAST and SCA techniques. At SonarSource, we’re currently focused on SAST with an eye on SCA as a future development focus. This isn’t to say DAST isn’t valuable; it’s more about relevance and context in your CI/CD workflow. DAST is based on black box testing and is implemented downstream of the development team. In contrast, an effective SAST strategy can fit right into your development process. If we’re being honest, there’s no legitimate reason for development teams to not embrace and automate a SAST program. This conveniently falls in line with all the “shift left” philosophies you’ve been hearing so much about. It’s all pretty straightforward - vulnerabilities are bad the developers introducing them should be the ones catching and eliminating them. So, why isn’t this actually happening in practice? The biggest reasons are:
- It can be very expensive to eliminate all your issues.
- You can’t shift everything left; there’s a reason security experts exists :)
- Improving issue detection will likely come with increased noise
You can’t get around these facts, but you can still put an effective and meaningful AppSec program in place. And that brings us back to a pragmatic approach where we think Security Hotspots keep noise generation low and help you stay focused.
Putting It All Together
In summary, an effective strategy combines the following concepts:
- Immediately act upon definite vulnerabilities, that our products can detect with specific techniques like taint analysis
- Fix known/definitive issue in the development environment and not downstream
- Use Security Hotspot analysis to focus review where it’s needed
- Utilize a dedicated person for hotspot review. This person can be a member of the development team who is more sensitive to security problems or someone outside the team specifically tasked with security reviews (who now has a good way to efficiently collaborate with the dev teams)
- Make the developers knowledgeable about the security risks associated with each kind of hotspot (i.e., educational tool for developers to increase security awareness).
Following these techniques will result in more secure applications. Yes, it will take some time and dedication, but it’s certainly achievable and maintainable over time. It’s an opportunity to reduce your vulnerability exposure while elevating your development team’s game - it’s all good vibes really!
New rules and languages are continuously added - check-out rules.sonarsource.com for the full, up-to-date listing.