Introducing Development Pipelines: Prioritize and secure high-risk repos and code

The goal of shifting security left and embedding it into developer tools and workflows is to make security feedback timely and relevant. When one developer or DevOps engineer has the context for one piece of code that contains issues, it’s easy for them to quickly review the relevant security feedback and make any necessary fixes. But in reality, developers work in dynamic, matrixed environments across numerous commits and branches. It’s easy to get overwhelmed with thousands of security best practices, and the additional complexity of having numerous repositories, developers, and teams makes it challenging to fully understand the security issues at hand.

So how can developers and DevOps engineers get insight into the status of their most important and active repos so that they can prioritize new and existing issues?

That’s where our newest Bridgecrew and Prisma Cloud platform addition, the Development Pipeline screen, comes in. Development Pipelines has replaced the previous Code Reviews screen and has two tabs—Projects and Code Reviews—which allow for better reviewing of open issues in repos and scans, respectively.

With graphical visualizations and lists that can be searched and sorted by various properties, these new screens help your team:

  • Maintain a zero-tolerance policy for misconfigurations in important repos
  • Prioritize the most severe issues in your latest code scans
  • Further investigate and quickly address high-priority issues
  • Define which findings should fail your code reviews and which should be only informational

Let’s see how.

Maintain a zero-tolerance policy for misconfigurations in important repos

In large-scale development organizations, DevOps engineers need to understand the security status of their repos—especially their mission-critical repos.

With the Development Pipeline screen, it’s easier than ever to keep an eye on your most important repos and prioritize high criticality issues in open pull/merge requests. The Development Pipeline’s Projects tab allows you to sort repos by:

  • Weekly commits: The number of merged weekly commits and how much that number has increased or decreased over the previous period.
  • Git users: The number of Git users who contributed code that was merged to the repository’s default branch.
  • Latest PR / MR scan time: The date and time the most recent pull/merge request was scanned by Bridgecrew.

When sorting by these properties, you can home in on repos with the most activity and users or by recent activity. We always recommend starting with the most important repos when dealing with large codebases, and now that’s easier to do with Bridgecrew.

Prioritize and address the most severe issues in your latest code scans

On top of prioritizing critical repos, the Development Pipeline’s Project tab helps you identify high-risk repos that have an unusually high number of misconfigurations and failed pull requests. The graph visualization shows repos with open pull/merge requests by their status—failed or passed—and you can sort the list of repos by:

  • Failed open PRs/MRs: The number of failed open pull/merge requests out of the total number of open pull/merge requests.
  • Pending Fix PRs/MRs: The number of fix merge/pull requests opened by Bridgecrew that are still pending.

Sorting by these properties makes it easier to determine which repos to prioritize based on the number of failing code reviews.

The Development Pipeline’s Code Reviews tab drills down even further, showing you your last 1,000 scan items by repo, organization, and item, and allows you to sort by:

  • Git user: The username of the Git user that committed the code that was scanned.
  • Scan failed issues: The number of misconfigurations flagged with a visual identifier of the highest severity identified. Selecting the value will provide a breakdown of misconfigurations by severity.
  • Scan status: Whether the scan passed or failed the system based on Enforcement rules. Selecting the value will provide details on the Enforcement rules that resulted in the failed or passed status.

Sorting by these properties will enable you to easily locate high-risk code reviews and identify their associated Git users. Not only will that help individual developers take action on their own faster, but also helps security teams identify which teams may benefit from dedicated security training.

Further investigate and quickly address high-priority issues

The Development Pipeline screen doesn’t just make it easier to prioritize efforts. It also makes it easier to take action. Hovering over the Project or Code Review row and selecting the Actions icon on the far right will give you options for what to do next.

In Code Reviews, and depending on whether the scan came from a VCS or a CLI run, you’ll have the option to:

  • View scan results: This will take you to the Bridgecrew scan in question to view diffs and misconfigurations one by one. You’ll also be able to suppress, fix, or create Jira tickets for them.
  • View scan results in VCS: If the scan was triggered by a VCS commit, this will take you to that commit in the VCS.

In Projects, and depending on the VCS, you’ll have the option to:

  • Review fix PRs in VCS: This will take you to your open fix pull requests (in GitHub only) if there are any for that repo.
  • Open the latest scan item: This will take you to the latest Bridgecrew scan for that repo.
  • Open failed PR scans in VCS: This will take you to a list of your failed pull requests (in GitHub only) that are open for that repo.

Define which findings should fail your code reviews and which should be only informational

As you’re prioritizing issues in your recent scans and high-priority repos, it’s also a good time to refine where and how feedback is being surfaced. You’ll notice that in the Development Pipeline Code Reviews tab, Bridgecrew will surface all violations of active (non-suppressed) policies, but that doesn’t mean the scan status is failing. Whether or not a scan results in a failed system (i.e. a failed CI/CD build) depends on the Enforcement rules.

With Enforcement rules, you can easily control how systems should behave when different misconfiguration severities—Low, Medium, High, Critical—for different code categories—IaC, secrets, Dockerfile images, and open-source packages—are identified. With Enforcement settings, you can set the following rules:

  • Hard Fail: The system will fail the run when a violation occurs.
  • Soft Fail: The system will notify the user about flagged violations but will not fail the run.
  • Comments Bot: The system will surface identified issues and fix suggestions as comments on VCS pull/merge requests.

You can also create Enforcement exceptions per repo. For example, in one repo, your team may only hard fail critical IaC misconfigurations but may also decide to hard fail image vulnerabilities. In this case, if that repo has IaC misconfigurations and image vulnerabilities, then the scan will fail. All Enforcement rules will be surfaced in the Development Pipeline Projects view.

···

Our new Development Pipeline screen gives you a searchable and sortable view of all your repos so that you can keep an eye on important repos, take action on high-risk scans, evaluate team knowledge gaps, and more. With greater visibility into your code security across your repos and scans, you’ll be able to prioritize security resources as efficiently as possible. To see this new addition and more in action, register for our upcoming Bridgecrew product demo and live Q&A.