Tip:
Highlight text to annotate it
X
In this demo, I’m going to show you how Tom, a developer, might interact with the
Coverity platform. Like many users, they have configured Coverity to analyze their project
in the background as part of their continuous integration, continuous delivery process.
It automatically assembles a comprehensive base of code intelligence, which it analyzes
to identify quality and security issues that developers need to address. We start the demo
as Tom arrives at work after checking in some changes the night before.
One of the first things Tom does is check his email.
Tom notices that Jenkins failed the build last night, and he has a Coverity notification
about some problems in his code. While most users have an email-based workflow like this,
it’s not the only option. You can base your workflow on other important tools like your
IDE, ALM system or bug tracking system if you prefer.
Tom likes to keep his code clean, so he addresses the Coverity issues first.
In fact, the Coverity failures actually triggered the failed build in Jenkins.
Opening the new issue, we go straight into the Coverity Connect web interface. Notice
how this issue has already been assigned to Tom, since he is the developer that committed
the code change. This is one way that the Coverity platform streamlines and automates
the developer workflow, minimizing housekeeping work.
Focusing on the source code, we can see that last night’s changes introduced a cross
site scripting vulnerability. In particular, Tom added a variable theme in the JSP to allow
for UI customization. The value is read directly from a request parameter on line nineteen,
and output directly into the response on line thirty.
In case you’re not familiar with a cross site scripting vulnerability, you can read
the info in the upper right which includes a link to the full CWE description. In short,
an attacker could craft a parameter value that executes javascript to get unauthorized
access to the user’s browser and private information when they access this page.
The remediation guidance in yellow tells Tom how to fix the problem. Namely, he needs to
sanitize theme before he outputs it. We actually detect the context hierarchy into which the
value is output, and the remediation advice tells you how to properly sanitize for that
specific context. In this case, Tom has a couple of steps, including using the Escape.uri
method from the open source Coverity Security Library to sanitize the value to be safe when
output as a URI inside an HTML attribute. Tom would normally fix the issue at this point,
but he wants to look at a resource leak that he didn’t have time to fix last night. He’s
going to update the status so he doesn’t waste time reviewing it later.
To see the resource leak, he can just pull up his outstanding issues right here. Tom
appreciates the convenience of having all of his action items in this one place.
This resource leak is pretty straightforward. We have requestInputStream, which is allocated
a resource in getFileFromZip. We can see that it’s not null since we take the false branch
on line three-ninety-nine, and it’s not released in the case where getStringFromInputStream
returns null. That getFileFromZip function is actually a
custom implementation, so how do we know that it allocates a resource. Simple. We analyze
all the functions to determine what they do. In this case, we can see that getFileFromZip
returns a new InputStream allocated on line five-fifty. Moreover, we follow that resource
as it is passed to getStringFromInputStream on line four-oh-one to verify that it isn’t
closed or reassigned there. This one also needs to be fixed, so Tom updates
the status and moves on to fixing the issues. Note how all issues are managed in the same
way. In fact, they funnel all their quality, security, architectural, and testing issues
into the Coverity platform, where they enjoy one consistent developer workflow that leverages
automated interactions with their build and bug tracking systems.
They are in the process of discussing a clean before checkin workflow, which would analyze
the code before it is checked in, so that developers fix problems even sooner. They
are still trying to decide which IDE the team wants to use as part of that transition. They
might decide to perform the analysis via a pre-commit hook in git. Either way, Coverity
has them covered. The Coverity platform enables developers to
focus on writing high-quality, secure code, without having to remember to run or check
various analysis, bug tracking, or other tools. The analysis tools run automatically as part
of the workflow, consolidating those findings so that developers can easily find and prioritize
everything in one place. The benefits of an automated, efficient developer
workflow extend beyond developers to management and teams like QA and security that work with
developer output. They enjoy greater visibility and predictability, leading to a more agile
and efficient process, and ultimately producing a higher quality, more feature rich offering
that end users can’t get enough of. To learn more about Coverity and how we can
help you, please visit our website or email info@coverity.com.