Our latest version of Code Dx — Code Dx 2.4 — will be coming out in the next few weeks. This release includes several minor tweaks, but the two most significant additions are support for Contrast Security’s Assess IAST solution, and new filters for temporal analysis of findings across scans.

Contrast Security Assess IAST support

Code Dx already supports over 40 tools and various testing techniques including SAST, DAST, manual, and third-party component analysis. With our 2.4 release, we’ve added a new testing technique, coined “Interactive Application Security Testing (IAST)” by Gartner. We’ve added IAST integration by incorporating compatibility with the Contrast Security Assess tool. IAST is a new application security technique that sits within a running application to detect vulnerabilities from within.

Code Dx Enterprise users can use the Tool Connector to automatically pull results from Contrast on a continuous basis without the need to download and upload scan reports — just open Code Dx to view the latest results. This includes identified custom code vulnerabilities and vulnerable or out-of-date third-party components. These results will get normalized, correlated, and merged with your other testing tools.

 

Age Filter

Many organizations have policies in place that say how long a finding can “dwell” before being fixed. For example, all High severity findings should be resolved within 30 days, all Medium severity findings should be resolved within 60 days, etc. For production applications, the longer a vulnerability sits around, the greater the chance that an attacker will exploit it. For vulnerabilities found prior to deployment, the earlier you can let developers know about it and work on remediating the problem, the better, since the changes that were made will still be fresh in their mind.

It’s good for an application security program to keep track of how long it takes for the development team to resolve security vulnerabilities. As more and more vulnerabilities dwell, there needs to be some change in the process to keep up with things — more resources need to be diverted to fixing them, development needs to slow down so remediation can catch up, or there needs to be a better understanding as to why the development team is falling behind.

The screenshot below demonstrates the new Age filter, where you can see a breakdown of the number of findings based on age. What is even more powerful is the ability to combine this with other filters, such as cross-referencing it with High severity vulnerabilities. Users can now easily examine SQL Injection vulnerabilities that were first identified between 30 and 90 days ago, for example.

Time/Version Filters

Many teams we’ve spoken with have requested several new filters, mostly concerning time or version history. Questions many development teams need their AppSec software to answer include: How many new findings were added since the last analysis, with the last code commit, between January and March, between version 1.0 and 1.2, or during development vs post-release? What is the general trend of findings being introduced — is the development adding more vulnerabilities than usually? How fast are we resolving issues? What type (e.g., XSS) of vulnerabilities are they? Which findings were fixed this year?

We have two new temporal filters to help answer these questions, one based on “First Seen” and the other based on “Last Modified.” A finding is “modified” when a comment is added or the findings is closed, and is first “seen” as soon as it is identified.

Each bar in the filter represents an analysis. The x-axis is based on analysis order, with bars evenly spaced or based on time. The height of the bars represents the number of findings either first seen or modified in that analysis, depending on the filter. Bars can be selected individually, or the time selector at the top can be used to select a range. The circles underneath each bar can be clicked to tag an analysis with a version name. Bars with version information will have a filled-in circle.

Version information can be added manually, or set from our Jenkins plugin or our REST API. This allows information such as the build number, commit ID, commit message, and author to be displayed with links back to your build server or the exact code commit that introduced the issue. This allows a developer to tie the findings back to the specific code commit that introduced them. The format and content of this version information is fully customizable.

Check it out!

The Code Dx team hopes you will find these new features useful. When 2.4 is released, a full list of changes can be found here. Don’t hesitate to contact us with your questions and comments. We appreciate feedback, and look forward to hearing from you.

If you haven’t used Code Dx yet, then request a free trial download today!