Skip to main content

By invitationVulkro Cloud · Code

Every repository and branch, checked before it merges.

The code app of Vulkro Cloud scans the repositories you connect, branch by branch. It holds every scan against a quality gate and reports the result on the pull request, where your team already reviews code.

Connect with an access token. Each scan runs in a container of its own.

acme.vulkro.comExample repository
  1. Every branch you trackEach one keeps its own issues, history and gate result. Switch from the header.
  2. Passed or failedEach scan is held against your quality gate. The default fails on a new Critical, a new High or a new secret.
  3. What started each scanThe schedule, a push, a pull request or a person, with the gate result beside it.

01Connect

Connect a repository with an access token.

Paste the repository's https address and a token from your git host, then choose the branches to track. A public repository needs no token.

  • GitHubCommit status, a summary comment and comments on the changed lines of each pull request.
  • GitLabCommit status, a summary comment and comments on the changed lines of each merge request.
  • BitbucketCommit status, comments, and a Code Insights report with each issue on its line.
  • Any git hostAny repository you can clone over https, scanned on a schedule. Servers you host yourself from the Business plan.
  • Tracked branchesChoose the branches to keep. Each one gets its own issues, history and gate result.
  • On a scheduleEvery 6 hours, daily or weekly, per branch, within what your plan allows.
  • On every pushYour git host tells Vulkro Cloud about each push through a signed webhook, and the branch is scanned. On the Team plan and above.
  • A token for each repositoryA token is kept for its own repository and used only for what you turn on there.

02Gates and pull requests

A clear pass or fail on every pull request.

Each pull request is scanned and held against the quality gate of its target branch. The result shows on the pull request itself, so nobody has to open another tool to see it.

git.acme.devYour git host
  1. One summary commentNew issues by severity, the gate result and a link to the scan. Updated in place on every new commit.
  2. Comments on the changed linesEach new issue on a line the pull request changed, with why it matters and how to fix it.
  3. A status beside your own checksPassed or failed, so your branch rules can require it before a merge.
  • Quality gatesConditions on new Critical, High or Medium issues, new proven issues, new secrets and open issues. The default gate fails on a new Critical, a new High or a new secret.
  • One gate or severalOne default gate for the workspace, or a gate of its own for a repository that needs a stricter rule.
  • Only what is newWith the default gate, a pull request is judged on what it adds against its target branch, so old issues do not block new work.
  • Which planQuality gates and scan on push come with the Team plan, the plan the 14-day trial runs on. Pull-request checks come with the Business plan and above.

03Each repository

The whole application, for every branch.

Every scan maps the application the way an attacker would see it, not only the list of issues. Each view opens from the repository's Explore menu, and every finding links to the code behind it.

  • API and accessEvery endpoint, who can call it, and whether your API specification documents it.Endpoints · API Spec · Access Matrix · Protocols
  • Data flowWhere request data goes, across files and functions, to the database, files and shell.Data Flow · Data Lineage
  • DatabaseTables, columns and the keys between them, with sensitive columns marked.Tables · Columns · Relationships
  • Code graphHow the code fits together, and what a change would touch.Structure Map · Imports · Impact · Files
  • SecretsKeys and passwords in the code, and in its git history.Secrets · Git history
  • Dependencies and licencesEvery package, its known vulnerabilities and its licence.Dependencies · Vulnerabilities · Licences
  • Attack pathsHow someone gets from an entry point to your data, and the kind of flaw on the way.Attack Paths
  • Code healthThe files that change most and carry most risk, and what the tests cover.Hotspots · Test Coverage
  • Dependencies, checked between scans tooAt every scan, and once a day after it: Vulkro Cloud checks your dependencies against newly published advisories, without a new scan. These lookups send package names and versions to the public OSV vulnerability database (api.osv.dev, operated by Google), never code. An admin can turn them off.
  • ExportsFor each branch: an SBOM in CycloneDX or SPDX, VEX, SARIF, CSV and a PDF report.

04Your data model

Your data model, read from the code.

Vulkro Cloud reads your ORM models and migrations, builds the tables and the keys between them, and marks the columns that hold sensitive data. Then it checks the design itself.

Read from
  • Prisma
  • Drizzle
  • Mongoose
  • TypeORM
  • MikroORM
  • Sequelize
  • Knex
  • SQL migrations
  • Django
  • SQLAlchemy
  • Alembic
  • Rails
  • JPA and Hibernate
  • GORM
  • ent
  • EF Core
  • Laravel
What it checks
  • A password column written without hashing
  • A token, key or secret column stored as plain text
  • A login email or username that is not unique
  • A table of sensitive data with no tenant column, when the rest have one

Scanning on your own machine? The same data model is part of the scanner's JSON output.

acme.vulkro.comExample repository
  1. The tables and their keysDrawn from the models and migrations in the repository.
  2. Sensitive columns markedPersonal data, money, health data, secrets and credentials.
  3. A risk in the design itselfHere, a password column that the code writes without hashing.

Connect your first repository in a 14-day trial of the full workspace.