Many security tools today are designed by security experts for security experts, but ultimately it’s the developers who both introduce and fix the flaws once they’re found. In order to embrace developers, the results of these tools need to be displayed where they spend most of their day: their integrated development environment (IDE), such as Eclipse or Visual Studio. Forcing developers to switch to another application to review security and quality issues gives them yet another reason to ignore these issues.
With our latest release of Code Dx, version 1.6, we’ve added two IDE plugins: Eclipse and Visual Studio. Now Security Analysts and Auditors can triage the results of all of their static analysis tools and push them to developers directly in their IDE. Developers can then filter on findings assigned to them, drill-into the exact line of code where the issues exist, add a comment, and fix the problem. This provides a bridge between the security team and developers, encouraging a team approach to application security, rather than opposing silos.
Open-source static analysis tools are typically geared around individual developers and do not provide enterprise team collaboration features. This is the added value that Code Dx brings. For example development managers and security professionals can see a centralized view of the state of an application, security and development teams can collaborate (assign task, change status, add comments) – security teams using the web interface and developers using their IDE.
Save money and catch flaws during development instead of when it’s too costly!
Another feature of Code Dx’s IDE plugins is the ability to run an analysis right from the IDE, before the code is even checked-in. Now developers can run Code Dx’s bundled tools during the development process, when it’s proven to be significantly cheaper to fix as described by NIST and Barry Boehm in his EQUITY keynote.
The more automated checks that can be done earlier in the SDLC the better. More and more organizations are looking for ways to push security to the left rather than it being done just before a release. No developer wants to receive a long list of issues right when they think they’re done. Typically the security team will give developers a big PDF report of all the issues they’ve found, and developers are stuck trying to track down where the problems are in the code or even if they are indeed a problem at all, i.e., not a false positive. This is often times the case since the security team doesn’t understand the application internals like the developers does. With the advent of agile development, continuous integration/deployment, and DevOps, the existing ways of preventing security errors is just not going to scale. Instead, continuous assurance is necessary and as described by Gary McGraw of Cigital and Jim Routh of Aetna, the key to success in scalability is “getting developers to do it”.
Test early and often. By doing this developers will find out about problems while it still fresh in their mind and not as risky to change – do you really want to be making code changes right before a release? They will also learn as they develop, which will prevent them from making the same mistakes over and over again. And it puts the developer in control, following a more self-service model to static analysis testing. This doesn’t mean a security team shouldn’t also do a review, but the hope is most of the low-hanging fruit would have already been addressed, making the security teams job easier and more effective and allowing them to focus their expertise on the more complex issues.