Why Binary Risk Management is Similar to Managing Your Wardrobe

Why Binary Risk Management is Similar to Managing Your Wardrobe

As we bid adieu to 2016 and welcome 2017, I'm thinking about the shift from the Continuous Integration (CI)/Build step to the binary repository space as a new control point within the software development cycle. Such dramatic changes aren't new in the software world, but what suprises me most is how much influence it has had over enterprise compliance and security teams who don't really understand why the process is changing.

Creating a Common Control Point

Recently, I learned that big enterprises do not use a standard sets tools and practices, making it difficult to have a common control point for monitoring code. A binary repository like Artifactory aggregates build deployments from multiple CI/Build systems; curating a common control point for Black Duck to run and display associated open source risk information. Having a solution at the repository level for this use case makes sense. However, people tend to forget that not everything in the sandbox (such as old proxied components from Maven Central) gets used in the product. There are components and code just lying around for years without anyone even touching it. Scanning and analyzing risk for those components is useless and adds additional stress for the security and compliance teams, not to mention creating significant delays in getting solutions to the market.

Binary Risk Management 

This is where I think your binary risk management implementation should be more like your wardrobe. You don't launder clothes that you don’t like or don’t fit just to make sure that the lucky date shirt is also clean and ironed. True? Artifacts and components need to be treated in the same way. Not all artifacts housed in the repository have to be scanned. When needed, they can be pulled down from the sandbox into your CI/Build, where a post-build Black Duck scan checks for and flags violations and security vulnerabilities.

We support this option for a variety of CI tools: Jenkins, Bamboo, TeamCity & Team Foundation Server (TFS). Randy Kilmon describes how we manage compliance with build tools at Black Duck in more detail in this post. And this way you can continue to use the CI/Build step as your default control point. You can also use our just released Hub-Artifactory integration with our Hub-CI integrations to scan and provide information at the repository level for release level candidates such as .zip, .war and so on. This implementation invokes a Black Duck scan on the Artifactory (AF) server and displays results in the Black Duck Hub. Alongside the Hub, it also exposes some vital metrics in the AF UI. Examples in the screenshot below:

Artifact Repository Browser

  • blackDuckScanResult: The binary status on the scan results.
  • blackDuckScanTime: Each scan is associated with a time stamp to attribute recency while analyzing results.
    Please note: a file that was previously scanned can be configured to rescan at a specific time, configurable via a cron job.
  • blackDuckProjectVersionUrl: The URL for the Project/Version report highlighting the different components and risks in the scanned artifact.
  • blackDuckProjectVersionUiUrl: The URL for the Project/Version report in the Black Duck Hub highlighting the different components and risks in the scanned artifact.
  • blackDuckPolicyStatus: A policy check field that lists components violating a pre-configured policy or featuring any security vulnerabilities.
  • blackDuckOverallPolicyStatus: Overall policy status (policy violations and security vulnerabilities).

Bulk Artifact Scanning?

In my opinion, full repository/bulk artifact scanning is not the best way to manage open source risk in your artifacts. Using the Hub-CI plugin with the Hub-Artifactory integration can help you add additional control at the repository level without compromising on any existing CI/Build compliance and security protocols you have set up. It can also help you avoid introducing any new systems into the mix.

The Black Duck Hub scanner aggregates multiple pieces of evidence at the CI/Build stage via its proprietary scan and dependency interceptions to give accurate and more comprehensive discoveries. This is why plugging the Black Duck Hub at the CI/Build step is pivotal to the success of your open source risk management program. The Hub Artifactory integration will do a second check at the repository level just for that additional level of control. If you feel going further left is better for your organization, we also have a Hub-Eclipse plugin. Between Hub Eclipse: Hub CI (managing upstream) and Hub-CI: Hub Artifactory (managing downstream), we have you covered!

All integration implementations are open sourced and available on Github.  

If you haven’t already, try the Black Duck Hub today to help you better manage the use of open source software in your application. 

Want to contribute to this project with new features and/or use cases? Visit here to talk directly with our Product team. 

eBook: How Mature is Your Open Source Risk Maturity Model?

0 Comments
Sorry we missed you! We close comments for older posts, but we still want to hear from you. Tweet @black_duck_sw to continue the discussion.
0 Comments

MORE BY THIS AUTHOR

Hub Detect: Comprehensive Open Source Scanning

| Aug 22, 2017

As a product manager at Black Duck, I drive our priorities with integrations. This means, of course, that I listen to our customers a lot — what integrations are working for them, what’s missing, and what new features would help them. Based on customer feedback, our team has been improving our

| MORE >

Scan Nirvana: Hub Detect for All Native Build & CI Tools

| Aug 15, 2017

When you’re trying to secure and manage the open source code in your applications, the first step is to accurately discover all the open source in your systems. Simply put, if you don’t know which open source components you’re using, you can’t protect yourself from vulnerabilities in those

| MORE >