Findings Management: Focus on the Security Bugs That Matter

Introducing Findings Management

Engineers using StackHawk today on local environments or in the CI pipeline will commonly fix High or Medium severity issues on the fly. It’s easy to do so when you’re in context of the code. But there are also circumstances where you are not ready to action on a particular finding.

It may be the case that expertise of another team member is required to solve the issue in which case a ticket needs to be created to assign the security bug to be included in a sprint. And let’s be honest, not all findings are created equal. While dynamic application security testing is better at limiting the noise of false positive alerts than other types of scanners, it’s possible that your team will deem certain Low findings as noise. The last thing you need as a developer is to continue getting alerted about findings that you’ve already processed.

Quiet the noise and focus on what matters.

With StackHawk’s new Findings Management, you can process your findings, marking them as Assigned, False Positive, or Risk Accepted. In future scans, these findings will still be tracked and visible in the UI, but only new findings will be positioned to grab your attention. With your findings processed, you can fix net-new security bugs as you develop software. With StackHawk scans in your CI pipeline , you’ll be alerted when a new bug is introduced and will have confidence in the security of your application when you have passing builds.

How it Works

Processing Findings

As you click into a finding, you’ll see a list of the paths where that finding was identified. From this screen, you can click into a specific path to see the details of the finding. This includes the Request and Response payloads, evidence of the finding (when applicable), a button for curl Validation , and Actions you can take on this URL. From this screen, you can process the finding for this particular path.

If you want to take action on multiple paths for that particular finding, you can use the checkboxes on the left to select multiple or all paths and apply the finding more globally. As an example, you may use a third party javascript tool that triggers a Cross-Domain JavaScript Source File Inclusion finding across multiple paths. In this case, you would mark all of those paths as Risk Accepted.

When you take action on a particular finding, you will be prompted to enter comments. This process creates documentation on why the action was taken and allows you to tie it to workflow tools like Jira (hint: our Jira integration is coming soon!).

Processed Findings on Future Scan Runs

On future scan runs, the processed findings will still be tracked, but they will not be pushed as actionable items. On the Scans page, you will see processed findings denoted in gray, while actionable (new and unprocessed) findings will be called out.

Once you click into the results of a particular scan, you will see a list of findings, with the number of paths denoted by finding status.

Then, once you click into a particular finding, you will see the paths denoted by Status.

Finding Status

Let’s dig into the Finding Status a bit more to learn what the options mean and how you can use them.

New

Findings are marked as New when they do not yet have another status assigned. These are items to be fixed or processed with another action to update the status.

Assigned

These are findings that have been assigned for review and/or fix in whatever issue tracking tool your team uses. These are items that are in a backlog or are in process for investigation or fix. Deeper integrations with workflow tools such as Jira are coming soon. As you mark a finding as assigned, you can include a link to the associated ticket in the comments.

Risk Accepted

Some findings are technically potential security bugs or risks, but for one reason or another, you are electing not to fix them. In our previous example of Cross-Domain JavaScript Source File Inclusion, you may have chosen to include trusted vendors such as New Relic for APM or Segment for event tracking. In this case, you would mark all paths with the included script as Risk Accepted.

False Positive

Scan results may include findings that are actually false positives, and thus do not require a fix. These can be marked as false positives to quiet future noise.

Workflow Suggestion: Assign Initial Findings and Fix New

One of the challenges with getting started with application security is the backlog of findings that may come from your first scan. The long list of findings can feel daunting and can be a blocker to moving forward.

One option that we recommend to customers is to assign findings from your first scan according to your team’s workflow. This might mean that Medium and Low risk findings go into the engineering backlog for prioritization, and High risk findings are included in the current sprint. Or you may assign all existing items to the security team for their review.