> For the complete documentation index, see [llms.txt](https://docs.medcrypt.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.medcrypt.com/medcrypt-documentation/msi/review-your-threat-model/compare-with-pentest-or-scanner-findings.md). # Compare your threat model with pentest or scanner findings Import a penetration test report or security scanner output to see whether your threat model predicted what testing actually found. MSI reads each finding, links it to the threats in your Risk Register, and adds any attack the model missed as a newly discovered threat. ## Before you begin * Your organization's plan must include Threat Modeling. * Select the device and device version the test or scan covers. * Run a threat model for that version first. Findings attach to the threats in the Risk Register; without one, scanner findings are imported but not linked to any threat. ## Import a report 1. In the sidebar, select **Import Report**. If the device already has imports, the latest one opens. To add another, use the selector in the page header and select **+ New Import**. 2. Under **Report type**, choose **Pen test** or **Scanner**. 3. Upload your files using the steps for that report type below. Your imports are listed under **Previous imports** with their type, status, date, and who uploaded them. Select one to open it. ### Import a penetration test report 1. Select **Choose reports**, or drag one or more reports onto the upload area. Supported formats are .pdf, .docx, .md, .txt, .rtf, and .html, up to 50 MB each. Each report is imported on its own. 2. Wait while the import moves through **Reading the report** and **Linking to the register** to **Ready for review**. ### Import scanner or code-review output 1. Optional: in **What was scanned (optional)**, describe the target, for example a repository or firmware image. 2. Optional: in **Architecture element (optional)**, choose the device asset the scan covers. Without one, findings attach at **Device level**. 3. Select **Choose files**, or drag one or more files onto the upload area. The upload panel lists the formats MSI reads natively under **Natively supported**. Anything else, such as a findings write-up or another tool's export, is read by AI, and every quote is checked against the file. 4. Wait while the import moves through **Reading file** and **Linking to threats** to **Completed**. If a file is skipped, the upload panel lists it with the reason, such as **Already imported** or **Could not be read**. ## Understand how findings map to threats ### Pen test findings The summary at the top reports how many findings were already in your threat model, how many additional threats were discovered, how many need review, and how many quotes were verified against the report. Each finding shows how it reached a threat: | Match | Meaning | | -------------------------------------------------------- | ------------------------------------------------------------------------------------------ | | **Your threat model predicted this** | The finding matches a threat the model already had for that asset and STRIDE category. | | **Matched on title** | The finding was matched to an existing threat by its title. | | **Matched to the element — STRIDE category unconfirmed** | The finding hits the right asset, but the type of attack isn't confirmed. Check this link. | | **Additional threat discovered** | The attack wasn't in the register, so it was added as a new threat. | | **Linked by a reviewer** | Someone on your team linked it by hand. | A pen test finding that exploits a threat is treated as demonstrated evidence. In the Risk Register, filter **Evidence** by **Pen test (demonstrated)** to see these risks. Risk scores are only proposed from findings. They're never changed for you. The tester's own severity is shown as **Tester rated** and is kept separate from your risk score. Filter findings by **Disposition** (for example **Open**, **Closed**, or **Risk accepted**) or search with **Search findings...**. ### Scanner findings Scanner findings are kept as evidence. A scanner flagging a weakness is a lead to review, not proof of an exploit. Vulnerable dependencies go to the Vulnerabilities screen. The summary shows how many weakness classes in the scan your threat model anticipated, and counts findings by category, such as **Dependency (SCA)**, **Code (SAST)**, **Secret**, **Infrastructure as code**, **Dynamic (DAST)**, and **Code review**. Only open high or critical findings raise a new register row; weakness classes below that threshold are kept as findings only. Filter findings by **Category**, **Severity**, and **Status**. ## Review a finding * **Fix a wrong link**: on a finding, select **Withdraw link** and give a reason. For a pen test finding, select **Link to Threat** to link it to the right threat instead. * **Resolve a scanner finding**: choose **Mark fixed**, **False positive**, **Accept risk**, or **Hand back to scanner**, with an optional review note. ## Next steps * [Triage risks in the Risk Register](/medcrypt-documentation/msi/review-your-threat-model/triage-risks-in-the-risk-register.md): review the threats your findings proved or added. * [Review your threat model](/medcrypt-documentation/msi/review-your-threat-model.md): regenerate the model with what testing taught you. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.medcrypt.com/medcrypt-documentation/msi/review-your-threat-model/compare-with-pentest-or-scanner-findings.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.