Security testing · Vulnerability management Available now

Security findings become part of the release decision.

Read connected repositories' code, secret, dependency, and lockfile-based supply chain findings alongside failed tests, grouped by severity. A single critical or major vulnerability makes that run's release decision FAIL.

Request a demoExplore the platform

Start with one GitHub repository connection. Scan results are recorded by commit for each run.

What we check

Zero findings and "unknown" are different.

Collect enabled code scanning, secret scanning, and dependency alerts beside failed tests, grouped by severity. Disabled scans show "unknown," so untested areas are never mistaken for safe ones.

  • Code scanning: rule, severity, file, and line
  • Secret scanning: exposed key/token type and declaration location
  • Dependency alerts: package, affected version, and fixed version
  • Disabled scans are individually marked "unknown"

Finding details

Where it is. How to fix it.

Open a finding to see type, severity, location, affected scope, remediation, and source links in one view. Developers know what to change in the next commit without hunting for the original alert.

  • Location: file, package, version, and declaration in the lockfile
  • Affected scope: repositories and runs sharing the finding
  • Remediation: upgrade to a fixed version, or use a workaround
  • Source links: open the original alert and public vulnerability entry

Decision impact

Critical or major vulnerabilities mean FAIL.

Security findings use the same severity system as functional tests. Even if all tests pass, unresolved critical or major vulnerabilities mean FAIL. Upgrade to a fixed version and retest; the findings must be resolved before PASS.

  • Critical/major: FAIL for the run
  • Minor/trivial: retained in findings without causing FAIL
  • Show each run's decision impact with counts by severity
  • Record findings by commit for every run, so retests show what was resolved
More about release decisions

Finding types

Four finding types. One standard.

Different sources use the same severity levels and decision rules.

Dependencies

Known vulnerabilities from repository alerts and lockfile lookups. See the package, affected version, and fixed version together.

Malicious package

Packages reported as malicious in public vulnerability databases. Flagged separately as critical regardless of their reported severity, with removal guidance.

Secrets

Keys, tokens, and passwords committed to code. See their types and locations. Disabled repository secret scanning is marked unknown.

Code scanning

Code flagged by static analysis. Rule names, file/line locations, and severity are included in finding details.

Supply chain & malicious packages

From lockfiles to malicious packages.

Read installed package versions from lockfiles and check public vulnerability databases. This works independently of repository dependency alerts. Record the dependency tree by commit to trace when each version was introduced.

  • Lockfile-based lookup of direct and transitive dependency versions
  • Malicious packages flagged separately as critical
  • Dependency trees recorded per commit, with differences across runs
  • Guidance on fixed versions or workarounds when no fix is available
Request a demo

Frequently asked questions

Security testing FAQs

Must security scanning be enabled in the repository?
We read enabled code scanning, secret scanning, and dependency alerts. Disabled features show unknown, not zero, so gaps stay visible. Lockfile-based supply chain lookups work independently of repository settings.
What if we already use a security scanner?
The goal is to connect scan results to release decisions, not replace your scanner. GitHub security alerts and lockfile lookups are available now. External scanner connections are in preview.
What data do you read, and where is it stored?
Repository security alerts and lockfile package/version information become findings. The dependency tree at the commit is retained with the run. Deployment and data handling scope are detailed in Deployment & data handling.
Who fixes vulnerabilities?
Your development team fixes code and dependencies. Finding details include upgrade versions or workarounds for the next commit. With managed QA, experts triage findings, retest fixes, and write release memos.
What if we must release with a critical finding?
The decision stays FAIL; whether to release is your choice. Instead of overriding it, fix the dependency and retest for a new decision. History retains exactly which run supported the release.
Do you check cloud configurations?
Cloud checks for exposed repositories, excessive permissions, expired keys, and environment differences across releases are in preview. Discuss the scope for your project during consultation.

Connect security findings to your release decision.

Connect a repository and receive security findings and functional results in one decision from the first run. For help with triage and retesting, request a managed QA consultation.

Request a demoTalk about managed QA

sales@qoretix.com+82-33-242-0210Weekdays, 10:00–18:00 KST