Findings and vulnerabilities

Every scanner you connect reports findings in its own format and on its own screen, and the things a person finds - a penetration test, an access review - usually land in a document nobody reads again. Joopler pulls all of it into one place: a single findings register that shows what was found, how severe it is, where it came from, and what you decided to do about it.

One register, whatever found it

Findings arrive from three directions and land in the same register:

• Connected scanners, continuously (see the list below).
• Exercises you record - a penetration test, a disaster-recovery test, an internal audit, or a scan you ran yourself and uploaded.
• Access reviews - the accounts you decided to revoke become findings, so the decision is tracked through to the change actually being made in your identity provider.

One register rather than one per source, because two lists are two places to look and two chances to disagree about where you stand.

One timeline from every scanner

Joopler ingests findings from the vulnerability and code-security tools you connect and merges them into one de-duplicated view. Connected sources include:

• GitHub Dependabot - vulnerable dependencies in your repositories.
• Prowler - cloud security scanning.
• Snyk - dependency and code vulnerabilities.
• Semgrep - static analysis findings.
• GitGuardian - exposed secrets.
• Amazon Inspector - workload and image scanning.
• AWS Security Hub - aggregated AWS security findings.

The same underlying vulnerability reported by more than one scanner is collapsed into a single entry, so the timeline reflects your real exposure rather than a double count.

Severity rollup and tracking over time

Each finding carries a severity, and the timeline rolls those up so you can see your posture at a glance. Findings are tracked as open or remediated over time, so you can watch the open count come down as your team works through the backlog and show an auditor the trend across the period, not just a snapshot.

Auto-remediation when a finding clears

When a scanner stops reporting a finding on its next run, Joopler marks that finding remediated automatically and timestamps it. You do not have to close it by hand; the timeline keeps the historical record that it was found and when it was resolved.

Closing a finding with an outcome other than "fixed"

Not everything gets fixed, and pretending otherwise is how a register stops being true. You can close a finding three ways:

• Remediated - it was fixed.
• Accepted - you decided to live with it. This requires a reason, because an accepted risk with no rationale is indistinguishable from one that was ignored.
• Not applicable - it does not apply to your environment.

An auditor reading the register sees what you found, what you did, and why - which is a stronger answer than a register where everything is closed.

Feeds the "vulnerabilities are managed" control

The timeline is the live evidence behind your "vulnerabilities are managed" requirement control. Because the findings and their remediation are captured as signed evidence, the control is proven from real scanner output rather than a manual attestation, and it rolls up into every framework that requires vulnerability management. Alongside it, cadence controls track that host scanning and business- continuity exercises happen on schedule.