In this post, you will learn how to improve your application security within hours after you install CodeGreen at your local Bitbucket administrator.
_Recommended pre-reading:
_Intro to SCA – Software Composition Analysis (mergebase.com)
Atlassian Marketplace Link:
MergeBase CodeGreen (marketplace.atlassian.com)
Introduction
One of the main challenges with known vulnerabilities is how they mess with standard software lifecycles. A lot of traditional quality engineering relies on the old saying, “if it’s not broken, don’t touch it.” Known vulnerability announcements for popular open source libraries completely go against that since they are discovered and announced more or less at random.
A good known-vulnerability SCA solution needs to deal with three very different cadences through which known vulnerabilities will manifest themselves in your software:
If you’re serious about reducing open-source known vulnerabilities within your software assets, CodeGreen is a tool for getting real results company wide. CodeGreen puts known-vulnerability software composition analysis (SCA) scans directly in front of software engineers’ eyeballs.
A lot of application security work is done by following checklists and invoking security tools, and uploading artifacts to cloud URLs during coding and reviewing tasks. CodeGreen short circuits all that by inserting itself directly into your company’s software engineering workflow (as a Bitbucket plugin). From there, CodeGreen can inject a range of interventions customized to your corporate application security policy, from low-friction informational reports all the way to outright blocking. These interventions help you quickly get all of your software engineering teams onto the same page.
By attaching directly to the enterprise source-control system (as a Bitbucket plugin), GodeGreen is able to improve application security posture across the board for an entire organization. Your application security will improve within hours after your local Bitbucket administrator installs the CodeGreen plugin through Atlassian’s marketplace.
Vulnerabilities Arrive On Different Cadences
- New vulnerability announcements. Your application is not broken; in fact, it’s working great! Clients love it. Management is happy. But a known vulnerability has been discovered and published that could be exploited by criminals and bring your brand down. You have to fix it! You must upgrade the insecure library to a safer version.
- Accidental vulnerability import (“developer-as-vector”). Under this scenario, one of your developers unwittingly introduces a bad library version (that contains known vulnerabilities) into one of your systems. Just because a “known vulnerability” is known to the cyber security world at large does not mean it’s known to your own development staff!
- That terrifying first scan. This scenario is essentially a combination of the above two scenarios, albeit after several years of unmonitored vulnerability accumulation. The experience of running a first vulnerability scan can be so overwhelming and demoralising for staff that good SCA tools must account for this and provide strategies to manage the first scan.
CodeGreen is a unique tool in the SCA space in that it provides mitigations, reports, and controls designed specifically for these 3 cadences. The rest of this blog post goes into those capabilities in-depth.
For New-Vulnerability-Announcements: Add A Little Friction (Cadence #1)
Developers need to be aware of how newly discovered vulnerabilities affect their systems, but finding time to address these is always a balancing act based on risk, urgency, and other priorities. This is where CodeGreen can apply a little friction.
For Developer-As-Vector: Slam On The Brakes! (Cadence #2)
For cadence #2 (developer-as-vector), once awareness is in place, vulnerabilities should never come into software via this vector. The vast majority of software vulnerabilities are announced alongside a patched (fixed) release of the library. This means developers should never introduce vulnerable libraries into a software project unless such is absolutely unavoidable. This is where CodeGreen can slam on the brakes.
Managing That Terrifying First Scan (Cadence #3)
A lot of security tools are sold and marketed based on a simplified model of their operation – the tool is presented similarly to a flashlight. Turn on the light, and see into the darkness. But under the hood, the tool might offer dials and controls and subtleties to users to help make its operation more successful. CodeGreen is no exception here!
Under ideal operation, CodeGreen would be configured to apply maximum friction to encourage developers to eliminate all vulnerabilities, but that’s not tractable for most organizations, at least not at first.
To help make CodeGreen more practical, we allow repository administrators to adjust the CVSS thresholds at which the various CodeGreen mitigations become active:
We recommend setting these to more permissive values during your initial rollout and tightening them to more restrictive values as your teams’ application security maturity improves.
For example, in the beginning, you might want to enable only the CodeGreen double-push friction and set it to a CVSS 9.0 threshold and disable everything else. Make it an overt-term goal to clear out all 9.0 vulnerabilities and above.
(But always enable “block-net-new-vulnerabilities” because that’s the dreaded cadence #2!)
Once you’ve achieved that, increase the “double-push” control to use a CVSS threshold of 8.0 so it catches more vulnerabilities.
Meanwhile, enable the “requires dual-approval” control (much higher friction compared to double-push) and set that one to 9.0.
The final result here is interesting: any newly announced vulnerabilities will suddenly dramatically slow down development teams. The developer has a choice: find someone to approve their work, leaving the vulnerability in place, or just patch the brand new 9.8 vulnerability and avoid the dual approval.
Which would you choose?
It’s a lot like thoroughly cleaning a house methodically from top to bottom: once a given room is clean, you can lock its door to prevent any additional mess from occurring in the already cleaned room. Similarly, here you can clean out all the 9.0’s and above and then “lock the door” on them by turning on the dual-approval control.
Conclusion
GodeGreen improves application security posture across the board for your entire organization by embedding open-source known-vulnerability scans directly into your centralized git source control. Your application security will improve within hours after your local Bitbucket administrator installs it!
