Vulnerability Management

Vulnerabilities in Parascope surface along two paths: scanners that run in the build pipeline and on a weekly schedule, and people outside the company who report what they find. This page covers what happens once a finding exists on either path. Software Supply Chain documents the pipeline itself and publishes the commands that let you verify an image signature yourself.

Continuous scanning

Dependency, container, secret, and static-analysis scanners sit inside the single required status check that protects the main branch. A dependency CVE at CRITICAL or HIGH severity fails that check, so the fix has to land before the change it travels with.

The gate scans the tree as it stood at merge time, and vulnerability databases move afterwards. A separate workflow runs weekly and re-runs the filesystem and configuration scans against a freshly downloaded CVE database, alongside image scans of the published service packages. Those legs are gated on the scanner's exit code, and a failing run posts to the same notification channel the platform's production alerts use. The same run also scans the third-party images the deployment charts pin. Those legs report their findings without failing the run, apart from the registry component whose version this repository chooses, because a CVE in an image someone else publishes is cleared by that publisher shipping a fix.

Software Supply Chain describes each merge-gate scanner and says where the weekly run's evidence is kept.

How patches reach production

The third-party components the platform runs on, among them the identity service, the HA-managed PostgreSQL cluster, the message broker, and the workflow engine, are pinned to specific versions in the deployment charts. Moving one of those pins is an ordinary code change: it passes the same required check and ships down the same deploy path as a product change, which is the path described in Software Supply Chain.

Dependency updates arrive as pull requests opened automatically. Renovate watches the pinned digests, covering third-party GitHub Actions and Dockerfile base images, and it tracks the pinned versions of the scanner tools themselves so the tooling does not quietly age. Dependabot opens weekly pull requests for the Python and Node dependency sets, batching minor and patch bumps into one pull request per set and leaving major bumps as individual pull requests so a human reads them. Base-image digest bumps are not auto-merged. Whichever bot opens it, an update pull request passes the same gate as any other change.

What happens to a finding

A finding at critical or high severity in first-party dependencies fails the required check, so remediation is a precondition of merging. Software Supply Chain states the two qualifications on the word "required".

A CVE published after a merge has landed is picked up by the weekly run, which fails and notifies the operator, and the fix reaches production down the ordinary deploy path. Where the vulnerable code sits inside an image somebody else publishes, a fixed version has to exist upstream before anything can move; what moves on our side is the pinned version in the deployment chart, and the weekly run's report is where those findings sit until it does.

Accepted findings

Some findings cannot be actioned by upgrading, because the fixed version does not exist yet or the component is already at its newest release. A finding is accepted by adding an entry to a tracked ignore file in the repository, and every entry sits under a dated block that names its review trigger, the component covered, and the reason the finding was accepted. Adding an entry is therefore a reviewed change with an author and a date in git history, and both the merge gate and the weekly run read the same file.

Reporting a vulnerability

Send security reports to security@parascope.io. The Vulnerability Disclosure Policy is the authority on the details; in summary:

• Scope is the *.parascope.io services and the collector appliance image. The policy lists what falls outside that.
• Safe harbor applies to good-faith research, and the policy defines what good faith means here.
• Response times are published as a stage-by-stage table, from acknowledgment to fix.
• Recognition is a credit in release notes, with the reporter's consent. There is no monetary bounty.

What this does not cover

No third-party penetration test has been commissioned. What stands behind this page is automated tooling and the review the merge gate carries. Nobody outside the company has been paid to go looking. Compliance Posture states the audit position in full.

There is no per-cluster CVE inventory. The weekly image scan covers the build channel at its most recent build of main, which is evidence about that channel. It does not enumerate the vulnerabilities in the exact SHA-pinned images a particular tenant namespace is running today. If your review needs that for a specific service, ask security@parascope.io.

There is no published remediation SLA for scanner findings. The response times in the Vulnerability Disclosure Policy are written for vulnerabilities reported to us, and they apply to those. Findings our own scanners raise are worked through the mechanisms described above, and this page puts no clock on them.

Verify it yourself

• Read the disclosure policy at Vulnerability Disclosure Policy. Scope, safe harbor, the out-of-scope list and the response table are published in full, with no form in front of them.
• Test the acknowledgment target. Send a report to security@parascope.io and hold the reply against the acknowledgment window the policy publishes. A response commitment you can time is one you can check.
• Check the pipeline claims directly using the verification steps in Software Supply Chain, including the signature command and the negative control that proves it is a real identity check.
• Controls with their own verify pointers are listed in the control matrix. Anything this page leaves open goes to security@parascope.io.