Anchore Enterprise in the Red Hat Marketplace

Anchore Enterprise is now available through Red Hat Marketplace, an open cloud marketplace that makes it easier to discover and access certified software for container-based environments across the hybrid cloud.

Built in partnership by Red Hat and IBM, Red Hat Marketplace is designed to make it easy for developers, procurement teams and IT leaders to gain access to popular enterprise software. The software in the marketplace has all been tested and certified for Red Hat OpenShift Container Platform, so it runs anywhere OpenShift runs.

We think it’s important to know what’s inside the containers you build and ship. That’s why you should integrate deep container image inspection into every stage of the DevOps workflow. At Anchore, our mission is to make sure that’s easy. We are excited to offer Anchore Enterprise through the Red Hat Marketplace so it can be seamlessly discovered and deployed by software builders everywhere.

This has been a big week for our friendship with Red Hat! Just yesterday we released Development at Mach One, a white paper documenting our recent shared mission implementing DevSecOps with the United States Air Force. Read it to learn how powerful Anchore and Red Hat are when we work together with our customers. Then visit out our Red Hat Marketplace entry to get started with Anchore Enterprise today.

Development at Mach Speed, A Case Study

For a little over a year now, engineers at Anchore have been working alongside our friends at Red Hat on an important mission: helping the United States Department of Defense reinvent the way they consume, build, and deploy software.

The DoD, just like any major organization, builds and ships a lot of software. This software runs on all kinds of devices, from everyday smartphones to extremely specialized equipment. They have teams of developers working to maintain it all, supported by a network of vendors, consultants, and contractors. There is constant pressure to keep the pace of innovation up. But here’s where the similarities with typical organizations end: when a breach occurs, they stand to lose a whole lot more than just a customer. The DoD’s software ensures the success of critical missions, and that can mean life or death.

The answer lies in DevSecOps: the integration of security best practices into a fast-moving development process, using policy-driven automation to create a high level of confidence.

Our teams worked with the DoD to implement a flexible, container-based platform for software delivery powered by Red Hat OpenShift and Anchore Enterprise. With this platform, the DoD can maintain a streamlined, zero-trust security and compliance posture while releasing new software as frequently as mission conditions require.

To learn more about this project, download our free in depth case study.

Why We Care About CVEs

Common Vulnerabilities and Exposures, or “CVEs”, are identifiers for specific vulnerabilities. MITRE defines its CVE list as a “dictionary of publicly disclosed cybersecurity vulnerabilities and exposures that is free to search, use, and incorporate into products and services.” The CVE list feeds into the National Vulnerability Database (NVD).

CVEs allow teams to track vulnerabilities that directly impact their system. In modern DevSecOps environments, it is common for CVE’s to be discovered during both build and runtime. A CVE matters because it provides traceability for each vulnerability that adversely impacts software. It is a way to describe and manage a discrete vulnerability. The name of a CVE simply provides the year each vulnerability was detected, which is useful. But the truly impactful part of each CVE as it matters to our everyday users come from the data and various scoring methods associated with each one. The scoring, description, and intelligence associated with each CVE are far more important than the CVE identifier itself.

Anchore includes CVEs in our report generation as they are the primary way our customers trace the impact of a vulnerability on their images. In many popular attacks against container images, attackers focus on the software supply chain (such as storing malicious images in container registries, typosquatting attacks on packages/images, etc.) rather than probing an existing system for a specifically available exploit in a running image. That being said, beyond their value in identifying and tracking specific vulnerabilities, they lack the information required for a security team to take action.

So Now What?

But how does Anchore incorporate the importance of a CVE into their product? What can your team do to be more proactive with container security?

Your security team can definitely help prevent typosquatting (see a good story at The New Stack about typosquatting and the dangers associated) and the downloading of malicious (accidentally, hopefully) images by your developers. Anchore can both help with supply chain oriented attacks in addition to taking the information we know about CVEs and using that as actionable data in our scanning policy.

Whitelist/Blacklist Your Images and Packages

To prevent this, Anchore easily provides the ability to blacklist images that may be suspicious, malicious, or simply up to no good in a public container registry. Navigate to your “policy tab”, select Edit Policy, then navigate to the whitelisted blacklisting images tab here:

Under blacklisted images, you can select “let’s add one.” You will see the screen below that allows you to add an image based on name (providing the registry, repo, and tag), by image ID, or by SHA digest. Blacklisting assumes you already know what is malicious and what is not. A more proactive approach would be whitelisting ONLY the images you want to use so that any other images, malicious or otherwise, are flagged for review in Anchore before they hit production. You also have the option to take this a step further and whitelist/blacklist specific packages for your organization to prevent typosquatting attacks.

Similarly, typosquatting attacks can happen on URLs, images, and even individual packages as was the case here where python packages contained legitimate code but had a setup.py script that would gather hostname and user information that would be sent back to another system. To prevent these unfortunate events from occurring in your container workloads, Anchore provides the ability to inspect your packages and blacklist specific package contents. You can view package contents here to understand the complete packages and files within your image to hunt for potentially malicious packages that wouldn’t be identified by a CVE.

Anchore allows you to make user-defined policy so you can easily blacklist malicious packages that are independently discovered by your security team or a part of any threat intelligence you are acting upon.  You can do this by navigating to policy checks and either adding to an existing policy or creating a new one. For this example, I will create a specific policy called “Typosquatting Checks” here:

I will then tailor this policy for specific known malicious packages that may be impersonating legitimate packages, and create a stop action in Anchore for any image that contains a malicious/fake package as seen here where we blacklist urlib3 (malicious package) that is impersonating urllib3 (legitimate package).

Don’t Boil the CVE Ocean: Incorporate CVSS Scoring into Scanning

Another more proactive way to tackle the management of CVEs in your environment, albeit not perfect given some flaws of scoring, is to integrate scoring into your scanning policy. The Common Vulnerability Scoring System (CVSS) is “an open framework for communicating the characteristics and severity of software vulnerabilities.” A way of explaining this is depicted below:

Source: NVD

At a high level, you can correlate a CVE with its CVSS score to determine which CVEs have the greatest impact on your system by looking at two things:

  1. Exploitability
  2. Impact

The higher the score on either of these factors, the more concern it should have for your security team. If a CVE has a very high exploitation score of a 9.5, but has a very low impact with a score of 2.0 then maybe it shouldn’t be a high priority. The same is true if you have a high impact score, but low exploitation score, which can commonly be the case if an attack vector isn’t widely available or if certain privileges are required in order to execute the attack and actually exploit the vulnerability. There are many other things that should be looked at when assessing vulnerability exploitation such as attack vectors, associated privileges, and attack complexity.

We put the power in the hands of the security teams to define the terms of policy enforcement for their container images. One way to make an intuitive policy using Anchore is to click “Add New Policy.”

There are 10+ selectors you can use to create your policy, such as CVSS base score, exploitability score, impact score, and fix availability.

This way, you aren’t scanning “just to scan” and check the compliance box for your next audit. You are scanning proactively, using a collection of user-defined acceptance rule checks to generate an actionable list of vulnerability and compliance findings immediately addressable by your security team.  By taking these steps, your teams can gain more security insight about the containers they are using instead of routinely gathering the CVE’s and attempting to solve your security woes by boiling the entire “CVE ocean.”

Anchore and GitHub Actions, A Tutorial

In this blog we’re going to show you how, with very little code, you can add robust security scanning, alerting and reporting to your existing GitHub projects.

(If you don’t get why, check out our GitHub Actions intro blog for some more background).

First, go into your Github repository and find the Action tab; it should be about midway along, as shown in the screenshot below:

If you’ve not set up any actions in this repo before, you’ll be greeted by the default setup screen.

We’re going to skip this by selecting the option on the left-hand side titled, ‘set up this workflow yourself’. This link takes us to the Action editor. You’ll find it has some example code already in place. So, go ahead and replace it with the following workflow:

name: Anchore Scan
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - name: Docker Build
      run: docker build . --file Dockerfile --tag testrepo/testimage:latest
    - uses: anchore/scan-action@v1
      with:
        image-reference: "testrepo/testimage:latest"
        dockerfile-path: "./Dockerfile"
        fail-build: true

If you are unfamiliar with Github Action syntax, you can find an excellent guide here.

In this workflow, we are creating a job called ‘Anchore Scan’, and setting it to scan every time that code is pushed into the repository. In addition, we are checking out our source code into an Ubuntu container and building a container based on a Dockerfile found in the root of the project.

Once the container is built, we then utilize Anchore Engine by calling the anchore/scan-action integration. As you can see, the scan-action takes three parameters:

First, image-reference, refers to the tag of the Docker image we created in the previous step.

Next, the dockerfile-path, highlights the Dockerfile, within the source code that is used to build it.

Finally, we have the fail-build. This option marks the action as failed if Anchore Engine finds anything in breach of its default policy.

This workflow is already looking pretty good, but we’re going to take it a step further and post a Slack alert for failures, offering us interactive feedback on security issues.

For the next step, you’ll need a slack incoming webhook.

Once you have the webhook, add it as a secret to your Github repository by going into Settings and then Secrets in your repository settings. Name the secret SLACK_WEBHOOK, and then add the following code to the workflow:

  - name: Send alert
      if: failure()
      uses: rtCamp/[email protected]
      env:
        SLACK_CHANNEL: general
        SLACK_COLOR: '#3278BD'
        SLACK_ICON: https://github.com/rtCamp.png?size=48
        SLACK_MESSAGE: 'Post Content :rocket:'
        SLACK_TITLE: Post Title
        SLACK_USERNAME: rtCamp
        SLACK_WEBHOOK: ${{ secrets.SLACK_WEBHOOK }}

This code uses another custom action to send messages to slack. Note the if: failure() directive; this ensures that the message is only sent if our Anchore scan failed, which in most cases means it found a security issue (because, although we’re lovely people, you only really want to hear from us if there is a problem).

Last up, we’re going to add a final action to our workflow to collect the detailed reports that Anchore Engine provides when scanning a container. These reports contain relevant data such as the bill of materials, any CVEs found and detailed build logs (maybe you can think of a security-focused colleague who finds this sort of stuff compelling).

Add the following code to your workflow:

 - name: Upload artifact
      uses: actions/[email protected]
      with:
        name: AnchoreReports
        path: ./anchore-reports/

This code makes use of the upload-artifact Action. It takes the contents of the anchore-reports directory created by Anchore, zips it, and makes it available as a build artifact.

Now we’re ready to add our workflow. Click the ‘start commit’ button on the right-hand side, and commit the action to our repository. Since this is a code push into the repository, it triggers the workflow we’ve just created. Click on the actions tab in your repository to be taken to a list of workflows. On the left, you should see our workflow, and if you click on it, you’ll see the current output for the running job. Once it’s finished you should see output similar to the screenshot below:

If you examine the details of the `runanchore/scan` step inside the build log, you should see something similar to the following screenshot:

We’ve got a few warnings, but otherwise, we’re in good shape. Finally, clicking on the Artifacts tab on the top right-hand side downloads the Anchore Engine reports. This gives us an amazing depth of knowledge on the image we scanned.

With Github Actions, a few lines of YAML and Anchore Engine, you can embed container scanning into the developer workflow, pushing this increasingly crucial security practice left and into the hands of developers. This immediate and easy feedback helps you keep your projects and data secure, without an enormous overhead.

To check out the full documentation for Anchore Github Actions and take a more detailed look at additional functionality such as custom policies visit the GitHub page.

As always, we’d love to hear your feedback, and we hope you love using Anchore in Github as much as we do.

Anchore and GitHub Actions

GitHub gets a lot of love from most developers, and the team here at Anchore are no exception.

Deemed worthy of its own top-level tab in every repo, Actions is GitHub’s newest tool for automating your software workflows with world-class CI/CD. Users get DevOps pipelines with the ability to build, test, and deploy code directly from GitHub.

Add in Anchore to this already heady cocktail, and GitHub Actions can now deliver a practical DevSecOps workflow – straight from the repo.

This ensures that, when your container is ready to deploy into any environment, it has had a rigorous security scan. You deploy the code you intend to and nothing else; your dependencies are scanned, and any potentially nasty surprises made visible.

If we already have your undivided attention at this point, feel free to jump right into our tutorial, which shows you how, with very little code, you can add robust security scanning, alerting and reporting to your existing GitHub projects.

Meanwhile, if you are interested in more of the theory and reasoning behind Anchore, keep reading on…

Why Shift Left Using GitHub

Software development is now one of the most collaborative of all human endeavors. The web page you are reading right now is almost certainly the sum total of work from thousands of individual developers. Most of these people have never met each other, but they leverage each other’s work to create the technology that now underpins almost every facet of our daily lives.

This collaboration extends widely; almost every ‘smart’ device, from your TV right through to your car makes use of software written by developers from almost every part of the globe. It is a modern-day wonder that powers a dizzying pace of innovation.

And for many developers, GitHub has become the focus of much of this collaboration. It is more than just a place to store code, it is a vast, well-connected collaboration platform. Within GitHub, developers can share, review, reuse and work together on code, regardless of background or geographic location.

However, maintaining security is challenging in this new collaborative world. It is now almost impossible to manually apply any form of effective security. So, like the Operations teams before, security now has to team up with developers: DevOps is becoming DevSecOps. And like its predecessor, DevSecOps is all about embracing automation, fast feedback loops and, of course, collaboration.

Collectively, this trend is now widely referred to as ‘shifting left’.

Ok. So… why Shift Left Using GitHub?

1. The fast feedback loop

Security has long been seen as a final, irritating inconvenience in the development process. Preventing developers from moving on to the next task. Security considerations appeared as late-stage scrutiny, putting developers through the wringer of fixing issues, only to find another bug has popped-up, after yet another manual or late security intervention.

By marrying GitHub Actions and Anchore, developers get security feedback right alongside their existing unit tests. Fix, iterate, and fix again. Once your tests are clean, it’s ready to go. Security becomes part of the same workflow developers know and love.

2. Easy to set up, easy to use

GitHub is built for collaboration, and Actions are no exception. Anchor has done all the hard work for you, meaning you just need to include our Action and a handful of code. We’ve done the rest, giving you security and peace-of-mind without you having to tear your hair out managing complexity to get there.

3. One place to look

GitHub is where developers go to work. It is a tool they interact with throughout the day, using it to store, test and collaborate on code. By making security front and center in their favorite tool, it means they have one place to look. Put the information somewhere else, and after the first rush of curiosity, it’ll gather dust, unloved and uninspected. Anchore and GitHub Actions keep the security picture front and center.

4. Comprehensive and complete

The Anchore engine is a powerful, Open Source container security scanning tool that the GitHub action makes use of. You get almost the same level of scrutiny, and peace of mind that you would get from running it on your desktop. It’s the perfect mashup of automation and power. To make Anchore engine fit with the ethos of GitHub actions we’ve chosen defaults that offer fast, concise and actionable reports based on the container contents. However, if you want a slower, but more detailed scan that includes application packages, you can enable it by using the include-app-packages option found in the GitHub Action docs.

5. Policy as code

Because it’s the full Anchore Engine, it means you can define your security policy as code and make use of it in the Action. This is the perfect blend of a fast feedback loop for developers, based on a security practitioner’s insight. It’s like having your security team checking every element of your artifacts, 24/7, and letting the real practitioners drop the grunt work and focus on more valuable endeavors.

If this has whetted your appetite, then check out our tutorial on GitHub Actions, which will show you how to integrate some of Anchore’s open source peace-of-mind into your pipeline, with just a handful of code.

Anchore’s Approach to DevSecOps

Toolkits and orchestrators such as Docker and Kubernetes have been increasingly popular for companies wishing to containerize their applications and microservices. However, they also come with a responsibility for making sure these containers are secure. Whether your company builds web apps or deploys mission-critical software on jets, you should be thinking about ways to minimize your attack surface.

Aside from vandalizing and destroying company property, hackers can inflict massive damage simply by stealing data. In 2017, Equifax was fined over $500 million after customer data was stolen. British Airways and Uber have also been victims of data breaches and were fined hundreds of millions of dollars in recent years. With an average of 75 records being exploited every second, preventing bad actors from gaining access to your containers, pipelines, registries, databases, clusters and services is extremely important. Compliance isn’t just busywork, it keeps people (and their data) safe.

In this post, we’d like to discuss the unique approach Anchore takes to solving this problem. But before we get into that, let’s take a moment to define the buzzword that is probably the reason you’re reading this post: DevSecOps.

In a nutshell, DevSecOps is a modernized agile methodology that combines the efforts of development, operation and security teams. Working together to integrate security into every step of the development process, teams can deliver applications safely, at massive scale, without burdening them with heavyweight audits. DevSecOps helps teams catch issues early, before they cause damage and while they are still easy to fix. By making security a shared responsibility and shifting it left (towards developers and DevOps engineers), your company can deal with vulnerabilities before they enter production, saving time and reducing costs drastically.

In the following sections, we’ll cover a few unique reasons why organizations such as eBay, Cisco and the US Department of Defense have made Anchore a requirement in their software development lifecycle to help implement security with DevSecOps.

Lightweight Yet Powerful

At Anchore, we believe that everyone should know what’s inside the container images they build and consume. That is why the core of our solution is an open source tool, Anchore Engine, which performs deep image inspection and vulnerability scanning across all layers. When users scan an image, Anchore Engine generates a software bill of materials (SBOM) that consists of files, operating system packages, and software artifacts (including Node.JS NPM modules, Ruby GEMs, Java archives and Python packages). Anchore Engine also allows users to check for CVEs, secrets, exposed ports and many others, but more on that later!

Anchore Engine was designed to be flexible, so you can implement it anywhere:

  • If you’re a developer and want to do a one-time scan of a container image for vulnerabilities before pushing any code to version control, you can use our CLI or API
  • If you’re a DevOps engineer and wish to scan container images before pushing to or after pulling from a registry, you can easily integrate with your preferred CI/CD tool (CircleCI, Jenkins, GitHub Actions, GitLab) or perform inline scanning and analysis
  • If you’re a security engineer responsible for locking-down clusters, you can use our Kubernetes Admission Controller to prevent any pods from running vulnerable containers

Anchore Engine can be configured on any cloud platform or on-premises, as well as with any Docker V2 compatible registry (public or private). Regardless of where you’re using Anchore Engine or how you’re using it, it’s important to know the exact contents of your containers so appropriate security measures can be taken.

Strict But Adaptable

Anchore Engine enables users to create custom security rules that can be adapted to align with company policy. For example, users can create and define checks for vulnerabilities, package whitelists and blacklists, configuration file contents, leaked credentials, image manifest changes, exposed ports and more. These rules allow you to enforce strict security gates like Dockerfile gates, license gates and metadata gates (check out our docs for more info!) before running any risky containers.

You may have heard of Infrastructure-as-Code, but have you heard of Security-as-Code or Policy-as-Code? Because Anchore policies are standard text files, they can be managed like source code and versioned over time as the software supply chain evolves and best practices are developed.

In addition to Anchore Engine, we offer Anchore Enterprise, which includes many enhanced features such as an easy-to-use interface, an air-gapped feed service, and notifications with Slack, Jira, GitHub or Microsoft Teams. There are many more features and capabilities of both Anchore Engine and Anchore Enterprise, but that is a topic for a later post.

Compliant And Growing

Just days away from becoming a CNCF Kubernetes Certified Service Provider, Anchore has been working hard to help companies fulfill their security requirements. Oftentimes, we receive calls from security teams who were asked to make their software adhere to certain compliance standards. Anchore is proud to help organizations achieve NIST SP 800-190 compliance, CIS Benchmarks for Docker and Kubernetes, and best practices for building secure Docker Images.

If you work with government agencies and are interested in another level of compliance, please check out our newest product, Anchore Federal! It includes a bundle of policies created in collaboration with the United States Department of Defense that can provide out-of-the-box compliance with the required standards.

In this post, we’ve listed a few key reasons why organizations choose to use Anchore. You may have noticed we also interchangeably used the words “you” and “your company”. That’s because – in today’s world of containers – you, as the reader, have the responsibility of talking with your company about what it’s doing to prevent threats, why it should be implementing DevSecOps processes, and how Anchore can help through container security. We are here to help.