The Coverity Platform – From a Developer’s Perspective


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
[email protected]

Leave a Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

Copyright © 2019 Geted Tabs Online. All rights reserved.