The first two questions:
On April 7th, security teams around the world started asking two questions about the Heartbleed bug:
-
Did we ever use that? (If yes, proceed to question #2)
-
Where is it?
A couple of months ago, these two questions were rushing through the minds of every CISO and AppSec professional that were not living under rocks.
Their minds then raced to:
-
How severe is the threat?
-
How many places does it exist in production?
-
Are we using it in software development today? and
-
How quickly can we begin to remediate the threat before the attackers are at our door?
In the case of Heartbleed or Struts2, the open source components were relatively easy to identify. In other cases, a vigorous hunt ensues. And sometimes CISOs, Enterprise Architects, or AppSec professionals just don't know where to start.
We have no idea
They just didn’t know. At the RSA Conference this past February, I was talking with the head of application security at a firm with thousands of developers. The company develops a large variety of custom applications for their customers. He said he remembered his company's reaction to the Struts2 vulnerability. They knew they had used Struts2, but did not have a way to easily track down the component in any of the applications under development or in their customer's production environments.
What did they do? They sent an email to all of their customers alerting them of the potential vulnerability and asked the customer to look for it. If the customer found an occurrence of Struts, they were then to contact this company to figure out a plan of what to do next.
I know this company was not alone. Many others were in the same boat.
At the same time, can you imagine receiving a letter from GM telling you that they know of a defective transmission part in your car. You might have one of those parts but you might not. They aren't sure. They ask you to look for it. Now imagine, you find this specific transmission part on your car. Your next step is to bring it into the GM dealer. At the dealer, they'll decide if you need to replace the part, or perhaps just buy a whole new car.
Hmmm. This can't be the right approach.
I'll tell you in three seconds
At Sonatype, we do lots of things to help customers track and identify vulnerable or risky components across their software development lifecycles and into production. Did you know that we run over 32,000 repository health checks every day for our community of 40,000 organizations running Nexus?
Here is a screenshot of the new dashboard:
With an easy glimpse or simple search, you can find out what vulnerable components are in your applications or where they are currently being used across your application development operations.
Four things to know
I won't give you the full dashboard tour here, but if you contact us, we would be happy to walk you through it.
That being said, here are four take-aways for you to know about the dashboard and how to use it with our CLM offerings:
1. Searching and Filtering
The dashboard helps you quickly answer questions like:
- Do I have vulnerable or risky components?
- If yes, in what applications?
- Have those affected versions of my applications been released and are they still in production?
- When were the vulnerabilities discovered and introduced?
2. Trending
Thanks to the tracking of results over time you get some valuable trending information as well and get an idea of answers to questions like:
- Are we getting better at managing our vulnerable and risky components?
- Are we finding fewer or more of them?
- How quickly are we remediating issues?
- How many issues still require action?
3. Diving Deep
No dashboard would be a good overview if it did not also allow you to get down to the details. The CLM dashboard allows you to answer questions such as:
- If vulnerabilities are found, what should I do next?
- What alternative components might be available to remediate the problem?
- What policies are we violating by using those components?
4. Taking Action
And once you have seen the nitty, gritty details and you can involve your developers, security experts, operations team and others to cooperate and find answers to:
- How can we triage this issue?
- Once we see a violation, do we need to make changes to our policy to better react to similar problems in the future?
- With this particular issue, should we waive the policy violation?
- What sort of code and component fix do we need to make as next steps?
- How do we get these fixes out into production deployments as soon as possible?
The CLM dashboard provides everything you need to know starting with a good overview of your current component usage and any related issues allowing you to take the next steps.
.jpg)
