From Burp/ZAP to a Clean Findings Schema

By Shamita Senthil Kumar, Associate Consultant, Artais

Working in application or platform security, engineers will look to close security gaps in their projects. There are many useful scanner tools such as Burp Suite or OWASP ZAP that can export findings and the results are used to tackle issues. However, with duplication and inconsistency among hundreds of findings, engineers would struggle to understand context for the findings and create solutions. They will ignore reports that they do not trust.

This article walks through an approach for turning noisy scanner exports into consistent reporting artifacts that can be operationalized by teams. Engineers cannot efficiently examine a large vulnerability report full of nonactionable items and will experience cognitive fatigue. The goal is to enhance the outputs of these scanner tools by normalizing them through a workflow that can be adapted by security teams (i.e AppSec, Security-Focused Developers, Cybersecurity Students, etc). We'll work through implementation that tackles converting exports to a findings schema and adding layers of logical rules.

Issues With Raw Scanner Exports

Scanners do their job to detect issues, but don’t necessarily communicate them in the best format. They aren't designed with reporting in mind.

Duplication

Structural misconfigurations can create a ripple effect and hit the scan multiple times, creating several duplicate alerts. A scanner can trigger a seperate alert for every API endpoint, static asset, and page related to that misconfiguration. Each variation of the issue becomes a finding that needs to be investigated even though the base issue is the same. Engineers may start to overlook such duplications as results become more noisy and less helpful.

Instead, we need to focus on a root-cause structure to eliminate multiple of isolated alert variations. This solution will help reduce the load on the engineers working on vulnerability solutions.

Inconsistency

Between scanning tools, the same concepts are identified using different fields or reporting formats. Severity and related evidence vary based on data and identified issues, therefore combining results can be more of a hassle. Exports also miss steps for reproducible proof so engineers have a harder time to identify a solution.

Drift

If any detection tool finds an issue, why does the reported data look so different? This happens because the scanners prioritize different pieces of information based on their internal methods. Based on if they are a DAST or SAST tool, the scanner may focus on responses or source files. AppSec teams deal with this frequently; even if the tools root-cause analyze the same vulnerability, the results will need to be normalized in order to avoid mismatched or misunderstood data.

Uniform Findings Schema

A findings schema can provide stability, reproducibility, and clarity for conversions from various scanner exports. While scanner outputs change, the normalized version does not and it makes for clearer remediation. It also helps maintain a uniform process even if different tools or softwares are being used, therefore easier comparability.

Example

This is a potential format for a normalized schema - a scanner json export can be easily converted to this findings json format.

{
    "id": "unique identifier",
    "issue": "concise technical finding",
    "description": "expand on the finding and describe impact",
    "category": "broad category",
    "severity": "how serious is the issue?",
    "cwe": ["list of related CWEs"],
    "evidence": [
      {
        "summary": "describe the evidence",
        "reproducible": "steps for reproducible proof",
        "affected": "components that are impacted"
      }
    ],
    "reccomendation": "what action can be taken?",
    "source": ["what tool has found this?"]
}

Addressing Duplication

In order to eliminate duplication effectively, a deduplication logical rule can be implemented. This can take into account similar CWE groups, type of vulnerability, and affected components to group findings together accordingly.

Example

IF same cwe
AND same issue
AND same category
THEN merge findings

When merging duplicated issues, the highest severity should be kept and the evidence converted to a list in order to track different proof.

Addressing Suppression

Scanner reports can also pick up some false positives but these shouldn't be simply deleted. Having supression rules in place can keep noise under control while documenting these additional findings. These rules can group supressed findings but they should be reversible and traceable.

Common Cases

Rules would need to be individually created by case. Here are some examples:

• Misinterpreted configuration states

• Findings against closed or inaccessible ports

• Vulnerabilities extrapolated from conditions that are not present

Common Pitfalls

Report quality can weaken due to the following:

• Not including reproducible evidence information

• Different affected components with the same base issue being different findings

• Assigning severity without regarding context

Avoiding these will improve the impact of the results!

Reference Implementation

A typical pipeline should be a process similar to the following: scanner export -> normalize JSON findings -> dedupe & suppress -> output (Markdown / PDF)

Step 1: Input

The first stage of the pipeline would take a raw JSON export from a scanning tool as input. This can be integrated through a CI/CD pipeline associated with a certain project or application.

Step 2: Conversion

A Python program can convert the tool-specific schemas to the uniform findings schema for normalization. For example, it would take OWASP ZAP’s alert field or BurpSuite’s issueName and place it into the our schema's issue field.

Step 3: Logic Rules

The pipeline can then apply deduplication and suppression rules. This can group together different alert variations and also filter out whatever alerts are deemed false-positive scenarios.

Step 4: Markdown

Finally, a normalized JSON report can be exported to a readable Markdown format. Some solutions can also be automated as part of the CI/CD integration - given a normalized finding, a certain action can be set off. Most security teams utilize tools such as GitHub or Jira so associated tickets can be opened and assigned accordingly as well for sooner attention.

Final Thoughts

By creating a normalized findings schema and introducing logic rules to reduce noise, raw Burp or ZAP json exports can be turned into actionable result reports that engineers can use to implement solutions. Automated conversion can help maintain uniform formatting and reduce time needed to address these issues.