“Well, yeah, I can give the devs a new security tool, but I can’t make them use it.”
I was mid-way through dinner with an old college friend when he dropped this into the conversation. I’d told him I wanted to pick his brain about security issues and tools, but told him no matter what, I wouldn’t start to deliver a pitch.
Well, I kept my promise, but I think I must have given my tongue a bruise from biting it.
My friend told me about times when he’d gotten burned by low adoption rates: tools that seemed like they’d be a good fit, but just didn’t mesh with the developers.
The problem was, he said, in practice it doesn’t matter how good the tool is, or what it does. The devs simply don’t want to use another tool – at all. When they work around the tool, the risk reduction (and solution value) you hoped for becomes just another “unknown unknown,” waiting to wake you up in the night with a priority alert.
I could tell my friend was speaking from hard-won experience. The products he’d bought were from some of the biggest names in the industry, and he (or rather, his companies) had paid a lot of money for those lessons about the difference between leading a horse to water and making it drink.
But of course, when I’d talked to developer friends, they had their own version of this story. “They want us to check our code, but the scan results are almost all false positives,” said one. “They’ll tell you that they find all these vulnerabilities, but they don’t tell you only a small fraction are actually exploitable. I stopped using it because I had better things to do!”
It turns out that what everybody hates about these experiences is, actually, kind of the same … Devs. Security. It doesn’t matter who you are.
Nobody likes wasting time.
So how do you secure your open source components without the time waste?
At Mend, we started by thinking about what everybody really wants out of their security tool. What makes people feel like their time is time well spent?
Discovering vulnerabilities is fine – but what really matters is reducing risk. Whether you’re a developer or a security engineer, your time is best spent when you can reduce the most risk fastest.
We found out that a lot of competitors’ tools showed a lot of results but didn’t provide a good way to fix the problems they uncovered. They also didn’t allow central enforcement of policies, which meant everything depended on individual developers choosing to do the right thing every time, even when production deadlines were coming down hard.
It didn’t take long before the people using those tools started thinking of SCA as a box-ticking exercise, rather than a critical tool for defending their products and brands.
So we set about doing things differently. For developers, we’ve created a near-invisible experience built right into the repositories and CI/CD tools they’re already using, to stop the feeling of wasting time by switching tools. With Mend, developers can see what fixes will reduce their risk most and even automatically remediate vulnerabilities, with false positive detection that tells them when they can safely ignore a non-reachable vulnerability.
For security teams, we’ve got ultra-fast deployment to your whole organization, holistic reporting, malicious package blocking capabilities, and centralized policy enforcement (yes, that’s right, my college friend – you can make the devs use it, by requiring a Mend scan on commit or build).
Our customers don’t have to worry that they’re wasting their time when they deploy or use our solution. And the biggest key to unlocking solution value is scanning not only in the pipeline, but in the repository as well.
When customers want to maximize solution benefits from Mend SCA, we always advise scanning in the repository.
It’s more costly to fix defects in the pipeline. IDE integrations are a good “shift left,” but won’t allow you to centrally enforce your policies.
The repository represents a genuine “sweet spot” for SCA scans: you get the ability to centrally enforce policies on vulnerabilities and open source licenses, with lower cost and faster remediation than pipeline scanning.
Our repository integrations – including the newest member of our repo integration family, Mend for Bitbucket Cloud – take our mandate not to waste time seriously. So if you’re using BitBucket and you add our Mend plug-in, you can do it all, from detection to remediation, without ever leaving your Bitbucket Cloud repository.
Our customers can remediate 2.5 times more vulnerabilities with a repo integration versus a pipeline integration alone, and we see an 80% reduction in the average time to remediation. Mend’s repo integration scales from 10 to 10,000 developers in days.
Mend works another way to ensure that time is time well spent: a single automated pull request with Mend can fix multiple vulnerable transitive dependencies.
What’s more, Mend’s Merge Confidence feature helps to ensure you won’t break your build by identifying components that (according to our crowdsourced data) don’t play well with others. Mend users can avoid the pain of un-mergeable pull requests – or worse, a broken dependency in production – with a certainty score they can trust.
Result: you can pick the fix that’s most likely to work without breaking anything, and you get to go home on time – now that’s living the dream.
We also know no one’s got time to waste when new critical vulnerabilities are announced. That’s why our automatic remediations have led our customers to a 94% reduction in time to remediate after the announcement of new critical vulnerabilities like Log4j.
If you’re using Bitbucket Cloud, it’s probably because you (or someone in your organization) wanted to take advantage of its deep integrations with JIRA and low tool switching.
That’s why we dig the Atlassian Bitbucket approach. We’re really into keeping devs in the tools they love. Mend’s repository integration acts as an extension of the repository itself, offering robust capabilities that automatically boost security and move requests through JIRA without any need to switch tools.
Our solution isn’t flashy. In fact, it won’t change your devs’ UIs or your workflows much at all. But it does have what you need: accurate, prioritized risk reduction that really works, with the universal adoption you need for a tool to succeed.
My old college friend, this one’s for you: now you can make the horse drink.