What a finding should tell you

A static analysis report that says "buffer overflow in device.c, high severity" tells you that a rule matched. It does not say whether the code can be reached, what would have to be true for the overflow to happen, or how much of that the tool checked. The reader has to work those out before deciding what to do.

The Violet RE page publishes an illustrative finding that states them. It is marked as illustrative and is not a customer result. The library, the function and the evidence hash are placeholders. We use it here because it shows what we think a finding should carry.

The code

The example is fourteen lines of recovered C.

void load_device_name(const char *src)
{
    char name[64];
    strcpy(name, src);
    set_label(name);
}

int apply_config(const struct config *cfg)
{
    if (cfg->device_name == NULL)
        return -1;
    load_device_name(cfg->device_name);
    return 0;
}

strcpy copies bytes from src into name until it reaches a terminating null byte. It takes no length argument, so it knows nothing about the 64 bytes that name holds. If the string at src is 64 characters or longer, the copy writes past the end of the array. This weakness type is catalogued as CWE-120, buffer copy without checking size of input.

Whether it can happen here depends on code the listing does not show. apply_config checks that the pointer is not null and checks nothing else. The length of device_name is decided wherever the config structure is filled in.

The fields

The finding is numbered F-0007. It carries these fields.

The first rows identify the weakness. Remediation says what to do about it, and evidence ties the finding to the file. The rows that decide what the reader does next are conditions, confidence and limitations.

Conditions

The conditions field lists what must be true for the weakness to matter. There are two here. The copy has to be in a build that is reachable, and src has to be able to exceed the destination.

Each condition is a question that someone who knows the product can answer. Suppose device names are read from a fixed 32-byte field. Then the second condition fails and the finding can be closed with a reason. Suppose they arrive in a network request with no length check. Then it holds, and the fix in the remediation field is worth making today. In both cases the reader knows what to look at.

Without the field, the reader has to reconstruct the conditions from the code, and a second reader may reconstruct different ones.

Confidence

Severity and confidence are separate fields and answer separate questions. HIGH describes how serious the weakness would be if the conditions hold. PROBABLE describes how far the analysis got in showing that they do.

The Violet RE page explains the grade: the finding is marked probable because a text-pattern rule matched strcpy. Destination size, callers and reachability were not established. In its words, the finding "says so, rather than rounding up".

Rounding up is the failure we want to avoid. A rule matches, the weakness type is serious, and the report prints HIGH with nothing beside it. The reader takes the severity for the likelihood. When a few of those turn out to be unreachable, the reader stops trusting the rest of the list, including the entries that were right.

Limits

The limitations field records what the analysis did not do. In the example it names the kind of rule that matched, a text pattern. It lists three things that were not established: the destination bound, the callers and reachability. It ends with "target not executed".

That last item follows from how Violet RE works. The analysis is static and, on the public tier, targets are never executed. The page draws the consequence itself: nothing is run, so nothing is proven exploitable, and confirmation stays with the person who owns the code.

The cve_ids field reads "none claimed". The finding describes a pattern in this code and does not assert that the code matches any published vulnerability.

A limitations field also covers the case where there is no finding. Rule-based checks miss things, and the Violet RE page says so in those words. A clean result means none of the checks that ran found a match. The page adds that it is not a clearance.

Who decides

The page puts the position in one sentence: a finding is a candidate, not a verdict. The verdict comes from someone who can see the rest of the program, and the fields are there so that person knows where to start.

The example discussed here is on the Violet RE page, with the listing and the finding together, alongside the current status of the service.