Ask Me Anything sessions: A unique opportunity to learn more about Sigrid. Sign up now!

System-level Security

System-level security is one of the detailed technical views under Findings. This may be available for your system. It depends on which capabilities have been activated specifically for your system or portfolio.

Reaching the Security page

You can reach the system-level security view in different ways: Via the top menu (the Findings tab), clicking a capability on the System or Portfolio Overview pages, or clicking on a system from the Portfolio security view. See the system-level Overview page, navigating from the portfolio-level Overview page or navigating from the portfolio security view.

The tooling underlying this analysis is updated as often as possible. Therefore it may be possible that new findings are found even when code is unchanged (link to FAQ).

As an example, clicking on the Findings tab will show you a menu different capabilities (if available for your particular system). Here, with Security highlighted when hovering the mouse.

The security overview page shows a summary of findings, their change, age and estimated severity. Note that the Findings tab will remain highlighted in yellow.

The different elements in this page are:

Context and meaning of CVSS security metrics: from asset to risk

CVSS (Common Vulnerability Scoring System) is a security-industry standard metric on a 0-10 scale, to indicate how severe a security issue may be. It does not signify a definite security problem, nor does lack of CVSS (or 0 score) imply security. This uncertainty is at the core of system security and mostly dependent on context.

It is important to make some distinctions by defining the elements that are necessary to properly interpret the meaning of these numbers. To simplify matters, consider the following non-exhaustive definitions:

Sigrid’s CVSS score of Raw findings signify “potential severity”

We may use “risk” a lot in colloquial language, but in this context of system security, a lot has to co-occur before a risk manifests, as can be seen above. This is relevant in reading the CVSS scores in Sigrid, because without a triage and a verification context, CVSS does not mean vulnerability or risk. CVSS scores, even when unvalidated, are a useful indicator. Generally, triage/analyze raw security findings, you would follow the CVSS scores in descending order from “potentially most severe to - least severe”.

Sigrid’s CVSS scores are based on a CWE benchmark

CVSS originates in research done by the US government’s National Infrastructure Advisory Council (NIAC), further developed by the Forum of Incident Response and Security Teams (FIRST). CVSS is strongly associated with the administrations for CWEs and CVEs. CWEs are part of the authoritative list of weakness types known as the “Common Weakness Enumeration” by MITRE MITRE CWE website. For CVEs, see the National Vulnerability Database(NVD)). A CVE always contains a CWE, while the opposite is not necessarily true (e.g. a weakness that has not been shown to be exploitable). CWE has a hierarchical structure, so higher-level weaknesses implicitly contain lower-level ones.

Elaboration on the CWE benchmark calculation

The core idea of the CWE benchmark is that, since CWEs, CVEs and CVSSs are related, we can use CVSS data associated with CVEs to come up with a score for CWEs. A benchmarked CWE score (presented as CVSS in Sigrid) consists of the averaged CVSS scores of all linked CVEs. In this calculation process, a weighted mean is applied to Impact and Exploitability (these are part of the CVSS “Core metrics”). This configuration puts more weight on relatively infrequent, but severe vulnerabilities. In case that the size of the dataset is below a certain threshold, an algorithm will crawl through the CWE hierarchy to find more relevant data points.

For each CWE, we build its CWE hierarchy tree and determine their respective CVEs of the last 5 years and the CVE’s typical CVSS estimations by security experts. This is a benchmark of expert judgements. Since context is a large factor in the severity of a security issue, the CVSS scores assigned to CWEs are further split by their attack vectors (this data is available since Attack Vector [AV] is part of the CVSS calculation). This split allows to make a mapping on this technical context, which should be administered in Sigrid as Deployment type metadata (see metadata page, specifically the GUI to do this in Sigrid itself). This metadata emulates CVSS’ “Environmental metric group” and provides important context to interpret its scores. If this metadata has not been set, Sigrid conservatively assumes “public-facing”, hence the most exposed type of deployment. All the different deployment type options (as other types of metadata) can be seen on the Sigrid API metadata end point page, specifically the Deployment type section.

CVSS scores in Sigrid

The CVSS map adjusts to the filter that you may have used.

Based on the CVSS score of findings, they are marked and colored ranging from “Information”, “Low”, “Medium”, “High”, “Critical”.

Information: a CVSS score of “0”. These include anti-patterns that may not have a direct security impact but can still be significant.

Low: CVSS score between 0 and 3.9.

Medium: CVSS score between 4 and 6.9.

High: CVSS score >between 7 and 8.9.

Critical: CVSS score 9 or higher.

To have an idea of what a certain CVSS score approximates, see NIST’s current 3.1 calculator or a calculation preview of the to-be-released CVSS 4.0). Note that an earlier CVSS version 2 did not include a “Critical” vulnerability category.

Different statuses of security findings

These are the different statutes of findings. The status “Fixed” will be applied automatically if a finding is resolved. See FAQ:Fixed issues are auto-detected. The other statuses can be set. They are similar to those used for system maintainability refactoring candidates.

Different possible grouping of security findings

Different views can be selected in the left menu. security models. The menu selector on the left you to easily toggle between the different models in one view.

Note that here, the menu’s category in bold is the currently chosen grouping. Therefore, below, under the column “Description”, different statuses are shown. Because “Grouping” means that Sigrid will show you a summary, the number of findings are shown on the right column under “Findings”, such as [C]1, [H]1, [M]99+ and [I]99+. These abbreviate the severity of the findings based on their CVSS score, and their count. You can click on those for a listing of the detailed findings. See also the CVSS elaboration above.

In the Grouping menu in the top left under “Finding”, the following types of grouping can be set:

In “Location”, either “Component” or “File” grouping can be chosen. The Component group follows the maintainability grouping in components. Findings may fall outside of that grouping because of exclusions. Then they will show under the “Other” component. Examples might be binaries or package manager configuration files, which would be excluded for maintainability analysis and therefore not fall into a component for the purpose of maintainability calculations.

Under “Model”, different Models can be used to map findings on. This is in practice mostly a matter of preference or specific auditing requirements. Next to popular security models, SIG has developed its own model based on the ISO 25010 standard, which can also be chosen. These are based on the [SIG Evalution Criteria Security][].

A note on seeing the same file/finding multiple times

Analyzing security findings

You can group and sort the detailed view of security findings. The sorting offers you the following.

Below an example of a list of detailed findings.

In the top left you can see that the findings are not grouped. Therefore each finding is shown individually. Below, the “Grouping” menu under “Sorting”, sorting is set to CVSS severity. Therefore the highest risk findings are shown above. Note that for example the first two findings are Maven dependencies. These originate from Open Source Health.

If Remarks have been registered, they can be seen in the far right column with a mouseover or clicking on the text balloon. An example of a mouseover is shown here.

If you click on the finding, the source code of the finding will be shown with its details. Details such as Status, finding age, Origin (scanning tool), File location, Remarks (if available) or audit trail are all viewable here.

In the left panel, the specific line is highlighted in yellow, where a possible vulnerability may exist (in this case, OS injection). For details on e.g. the right panel, see Open Source Health-analysis section. Extra information such

Analyzing security findings: Dependency example (based on Open Source Health)

As above, starting from the findings overview: if you click on the finding, the source code of the finding will be shown with its details.

In case that the relevant line is not highlighted in yellow (this sometimes occurs in package management files), you can search within the file with cmd+f/ctrl+f. By default your browser takes precedence for this shortcut and therefore will try to search the page. You therefore need to move mouse focus to the left pane by clicking on the source code area or tabbing to the element first. You can use regular expressions if you wish so.

On the right side of the page, all details surrounding the finding are shown.

Changing a finding’s status and audit trail

In the top right, the Edit Finding button allows you to change e.g. its Status and Severity

In this case, because this is an automatically scanned dependency by Open Source Health, e.g. changing its status to “false positive” will not necessarily remove the finding indefinitely. As long as the OSH tooling finds the same result, it will return. See also this specific case in the Security FAQ. The same holds for the “Remark”. Findings by Open Source Health* automatically add the type of vulnerability and vulnerability (CVE) reference. Remarks can also be adjusted manually. Any user can edit remarks or other characteristics. This could also be a SIG consultant, depending on your specific Sigrid agreement.

An audit trail can be seen when clicking the “Show Audit Trail” button. In case of changes, multiple entries will be shown with their respective usernames and dates.

If available, the relevant CWE will be shown. The CWE link in the security finding will refer you to the OWASP Common Requirement Enumeration (CRE) page. This will show the CWE in context. SIG has been an active and proud contributor to this project in close collaboration with the world’s application security authority OWASP (Open Worldwide Application Security Project). CRE is an open source security reference knowledge base, a nexus between OWASP’s initiatives and relevant, authoritative security reference documents originating in MITRE, NIST and ISO.

An example of openCRE is shown below.

Linking to Code Explorer

On the top right you can show the code in the “Code Explorer”, which will show you the code’s context and related findings. See also Code Explorer.

A general, typical strategy for processing security findings

Especially when Security is enabled in Sigrid for the first time in your system, the number of findings may seem overwhelming. Therefore, filtering out false positives is your first concern. That will give you a more accurate view of the system’s risk exposure. And then you may set priorities, and writing explanations or recommendations for findings that need attention.

Threat modeling as a requisite for interpreting security findings

The absolutely most solid way to approach security is to start by threat modeling. This takes you a step back of all the technical findings. A threat modeling effort should involve brainstorms, whiteboarding and Data Flow Diagrams to reach a basic system threat model and its associated security risks.

There is wide availability of training and instruction regarding threat modeling e.g. OWASP’s Threat Modeling Cheat Sheet or the Threat model Wikipedia page, where the Threat Modeling book by Adam Shostack is probably considered one of the fundamentals.

As a simplification of a whole field of expertise, please do keep in mind:

  1. Start small. Do not strive for completeness on the first try.
  2. Assign ownership and repeat. Threat models are never finished and need a maintenance rhythm.

SIG can help with such threat analysis efforts as custom consultancy services. Please reach out to your account contact if you have questions.

Filtering results for false positives: starting with Open source vulnerabilities

In case of false positives, you may contact Sigrid Support. Given the automatic resolution of versions and vulnerabilities on which Sigrid is based, we are dependent on the data quality of our data sources, but we will see what we can do for you.

Prioritizing security findings

SIG may offer consultancy services to help you with security

Depending on your agreement with SIG, security expertise consultancy may be available. Or this can be offered as a separate consultancy effort. See also this question in the security FAQ.