A public vulnerability database gives a weakness one CVSS number. It cannot know whether your operators rely on the function an attack disrupts, or whether the vulnerable code even runs in your deployment. Teams that build connected products face two questions: where is our own product weak, and does a published vulnerability in a component we use affect us?
This demo answers both inside Polarion with Nextedy RISKSHEET. Risks, scores, the reasons behind them, third-party components and their vulnerabilities are all work items, linked to the controls that treat them.
Watch the walkthrough (5 min):
One product, two questions
The example is a Remote Monitoring App: a cloud service with a web dashboard, a mobile app and a gateway on site that connects the monitored devices. Plants, hospitals, vehicle fleets and aircraft maintenance teams all run this pattern.
Two scores for every risk
In CVSS 4.0, published by FIRST in November 2023, the base metrics describe the weakness itself and give the generic score, CVSS-B. Threat and environment metrics add what is known about exploits and how this product is used, and give the CVSS Score. The risk sheet keeps both side by side, computed by the scoring code of FIRST's own calculator.
The difference matters. Alarm flooding (NCVSS-742) is 8.7 High on its own. Operators rely on the alarms, so availability matters most, and a missed alarm can leave a device in an unsafe state, so the impact on the devices is marked Safety: 9.7 Critical. A gateway that does not check the cloud server's certificate (NCVSS-745) scores 2.3 Low on its own, but operators act on what the gateway reports, so integrity counts: 7.0 High. Error pages that reveal the server version (NCVSS-751) fall from 6.9 to 2.7 Low, and the risk is accepted with its approver and an expiry date. The reason is written beside each score.
From finding to treated risk
Every risk follows one status flow: Identified, Scored, Treatment Decided, then Mitigated or Accepted. A new finding is typed straight into the sheet and scored as the engineer answers the base questions. For an open risk, the AI Assistant proposes controls that already exist in the project: for password reset links that never expire (NCVSS-747) it finds single-use reset links (NCVSS-731). Nothing changes until the engineer applies it.
Does a published vulnerability affect us?
The second question starts with the software bill of materials: eight real third-party components, each a work item, with ten real CVEs as published by the NVD. The vulnerability sheet puts the published score next to the answer for this product, its VEX status, in the Affects Us? column.
Six are Not Affected, each with the documented condition that rules it out. Spring4Shell (CVE-2022-22965) is published at 9.8, but it needs a WAR deployment, and this back end runs as a Spring Boot JAR. The pgjdbc SQL injection (CVE-2024-1597) needs PreferQueryMode=SIMPLE. A jackson-databind flaw (CVE-2020-36518), published at 7.5, does affect the product. It is linked to the product risk NCVSS-743 and scored with CVSS 4.0 for this deployment: 7.7 High. Log4Shell is recorded as fixed, and one CVE stays Under Investigation until somebody answers it.
The report answers both
The CVSS report reads the stored work items each time it opens: severity by status, where the environment changes the score, open risks without a control, accepted risks, and the published score against our assessment. Every number opens the risk sheet filtered to exactly the items behind it.
The method is configuration
The mapping to the CVSS vector and the severity bands are Polarion enumerations, so they can be renamed or translated. The score itself is not configurable: a changed lookup table would no longer be CVSS. The FDA premarket cybersecurity guidance, the EU Cyber Resilience Act, IEC 62443 and ISO/SAE 21434 all expect an SBOM and a defined way of handling vulnerabilities; here both live next to the product risks.
What this demo does not do
It does not show an import from an SBOM file or a vulnerability feed; the components and CVEs are entered as work items. Threat modelling of a product's interfaces is the job of STRIDE, which we show in a separate demo.
Talk to us
If you want to see CVSS 4.0 and third-party vulnerability assessment on your own product, book a meeting or read more about Risksheet.