Solutions · Application security

A disabled check is never a pass.

See connected repository code scans, secret scans, and dependency alerts with your release verdict. Critical or major vulnerabilities cause FAIL. Disabled checks show unavailable, not zero findings.

Request a demoExplore the platform

Supply chain and malicious packages

Start with the lockfile.

Read package versions from lockfiles and query public vulnerability databases. Packages reported as malicious are marked critical. Dependency trees are recorded by commit so you can trace when a package was introduced.

  • Show package, version, and declaration location
  • Reported malicious packages are always critical
  • Retain dependency trees at each commit
Explore security and vulnerability management

Decision impact

One critical vulnerability means FAIL.

Security findings use the same severity model as QA failures. Even if all tests pass, critical or major vulnerabilities produce FAIL. The verdict changes only after revalidation confirms resolution.

  • Critical or major vulnerabilities cause FAIL
  • Verdict cards list QA failures and security findings together as reasons
  • Immediate browser notifications for FAIL verdicts
  • Unavailable checks never count as passed

Remediation

Where it is. How to fix it.

Finding details include type, severity, file, package, version, declaration location, impact, remediation, and source links. Upgrade to a fixed version when available or follow a workaround. Findings are recorded by commit and checked again during revalidation.

  • File · Package · Version · Declaration location
  • Impact, remediation, and source links
  • Commit-based findings connected to revalidation

Finding types

Every finding type in one list.

Unresolved items combine failed checks and security findings, ordered from most severe.

Dependency vulnerabilities Available now

Compare package versions with public vulnerability databases to show impact and fixed versions.

Malicious package Available now

Packages reported as malicious are marked critical regardless of the original severity and cause FAIL.

Secrets Available now

Read repository secret-scanning alerts to show the type and location of exposed keys.

Code scanning Available now

Read code-scanning alerts, sort by severity, and link to the source.

Cloud checks Preview

Find public repositories, excessive permissions, and expired keys, and compare environment configurations at each release.

External security scanners Preview

Include other scanners' results in the same list and verdict.

Frequently asked questions

Before adding security checks

What repository permissions are required?
Connect through the GitHub App to read security alerts and lockfiles. Code is read only as needed for execution and case generation. Data processing scope is documented in Deployment & data handling and the contract.
What if repository security features are disabled?
Those checks show unavailable rather than zero findings and do not count as passed. Once enabled in the repository, alerts appear from the next run.
We already use a security scanner. Must we replace it?
No replacement is required. Repository alerts and supply-chain checks feed directly into verdicts. Integrations that bring other scanners into the same list are available in preview.
Who filters false positives?
Each finding includes a source link and impact details for your team to assess. With Managed QA, experts review security findings during triage and document them in release notes.
Are security and QA verdicts separate?
There is one verdict. Critical or major vulnerabilities appear as reasons on the same card as QA failures. Revalidate after fixes to update it.

Start with what you could not see.

Connect one repository to include security alerts and supply-chain findings in your first verdict.

Request a demoExplore the platform

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