Valqore: a containerised scanner that grades infrastructure against 1,431 rules
Safety-first guardrails for AI-driven cloud and Kubernetes operations
At a glance
- What is it?
- Pull one Docker image, point it at a manifest or a folder, and get a score, a PASS or BLOCK verdict, and 19 compliance packs of findings. Useful enough to run in a pipeline, and unusually candid about what the free image does and does not include.
- Who is it for?
- Valqore is a reasonable thing to trial in CI, because the free image needs nothing but Docker, decides deterministically without a model in the loop, and signs its artefacts so you can verify what you pulled. Three things to settle first.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 34 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 9, 2026, and from our analysis. They are not legal advice.
Editorial analysis
One image, one command, one score
The quickstart is three commands. Pull the public image, which the README says is free and needs no signup:
docker pull ghcr.io/valqore/engine:latestThen scan a file. Note the volume mount and the working directory, which is how the container reaches your files:
docker run --rm -v "$PWD:/work" -w /work \
ghcr.io/valqore/engine:latest valqore evaluate deploy.yaml --scoreThe output is a score from 0 to 100 and a verdict of PASS, PASS_WITH_MONITORING or BLOCK. That three-value verdict is the design decision worth noting, because a plain pass or fail gives you no way to express a finding you want visible but not blocking, which is the normal state of an adoption rollout.
The third quickstart step solves the ergonomics problem the long prefix creates, by aliasing the whole invocation to `valqore`. Once that alias exists, the commands read like a native tool:
valqore evaluate deploy.yaml --score # one file
valqore evaluate ./k8s/ --score # a whole folder
valqore agent-audit ./k8s/ # who governs your AI agents?The README is honest that every later example assumes the alias, and tells you to put the full `docker run` prefix back if you did not set it. That kind of note is small and saves real confusion.
Docker is the only prerequisite, on Linux, macOS or Windows. There is no pip install path and no binary download, which is also why the image is the only artifact you can inspect.
The repository holds documents, not the engine
GitHub reports the primary language of this repository as Python. The file listing contains no Python source. What it contains is `.github/`, `action/`, `benchmarks/`, `blog/`, `examples/`, `integrations/`, `partners/`, `whitepapers/`, plus `CONTRIBUTING.md`, `SECURITY.md`, `SECURITY-FAQ.md`, `TRUST.md`, `cosign.pub`, a `.gitignore` and a `LICENSE`.
That is a documentation and examples repository that happens to be tagged Python, and the mismatch is not cosmetic. If you want to know what a rule actually checks, it is not in this repository.
The release notes point somewhere more specific. All three recent releases carry `docker pull` instructions for `ghcr.io/valqore/engine`, the cosign examples verify an identity matching `https://github.com/valqore/valqore-engine/.*`, and the v1.13.5 changelog links a compare view on `valqore-engine`. The engine lives in a separate repository under the same organisation, and this one is the front door.
Two further details make the same point from a different angle. The README states the public image is compiled native code with no readable source, and the LICENSE file sits alongside `TRUST.md` and `SECURITY-FAQ.md`, which is the documentation set a vendor maintains when the artefact is a binary rather than a codebase.
The `examples/` directory is the most useful part to browse from here. It holds eighteen scenario directories, including `agent-gate/`, `ai-governance/`, `ai-scan/`, `fintech/`, `greenops/`, `saas-platform/`, `supply-chain/`, `verify-evidence/` and `versus_incident_gate/`. Those are effectively the documentation of what the rules expect to see, written as input files you can scan yourself.
What the free image includes and what costs a license
There are two images, and the README draws the line between them explicitly. The public `ghcr.io/valqore/engine:latest` is described as free, public and tokenless, and the table credits it with all 1,431 rules, scoring, drift detection, billing, compliance and the MCP server. The `engine-ai` image is licensed and available on request, and it adds the embedded offline model behind AI Scan and chat.
That the AI features are the licensed part is the design philosophy stated in the v1.13.6 notes: AI explains, rules decide. The reasoning is sound, because a model in the enforcement path makes every verdict non-reproducible, and this tool's selling point is that the same rule set produces the same control-mapped evidence for nineteen frameworks.
Activation is a persistent volume plus a license key:
docker volume create valqore-data
docker run --rm -v valqore-data:/app/data ghcr.io/valqore/engine-ai:1.13.6 valqore activate YOUR_LICENSE_KEYThe README also states the AI image runs the fine-tuned model fully offline, so your code never leaves the container, and that the interactive chat surface answers questions about a scan, including remediation advice, compliance mapping and cost tips.
Worth being clear about what that buys you. Chat and AI Scan are ways of consuming results a human reads. The pass or block decision in a pipeline comes from the free image, so the license is not required to enforce anything.
Four surfaces beyond the CLI
The README lists five ways to run Valqore and the first is the CLI. The second is the one with real architectural interest: cluster enforcement through a Helm chart, using native Kubernetes admission control.
helm install valqore oci://ghcr.io/valqore/charts/valqore-stack \
--namespace valqore-system --create-namespace \
--set 'policies[0].name=enforce-owasp-agentic' \
--set 'policies[0].pack=owasp_agentic' \
--set 'policies[0].action=Warn'The claim is that this materialises eight native `ValidatingAdmissionPolicy` objects on the cluster, and that the Kubernetes API server enforces them. The README then states the important consequence in bold: Valqore is not in the data path. That is a meaningfully different design from a mutating webhook, because the API server rejects a bad workload on its own once the policies are installed, with no Valqore process serving requests and no added latency or availability risk.
You then confirm the policies landed:
kubectl get valqorepolicy enforce-owasp-agentic
# NAME PACK ACTION READYVAPS
# enforce-owasp-agentic owasp_agentic Warn 8`READYVAPS` reporting 8 is the check that matters, since it tells you how many API server policies are actually active. The workflow is to start at `Warn` and flip to `Deny` once you trust the rule, which is the right order for adoption.
The remaining three surfaces are an editor and an agent surface. There is a VS Code extension offering CodeLens, hover and quick fixes in YAML, Terraform and Helm, a Freelens extension for the Kubernetes IDE, and an MCP server for Claude and Cursor. The count of governance tools is stated as 137 in the README's table, while the v1.13.6 release notes call it the 136-tool MCP chat server, so treat the exact number as approximate.
GreenOps, agent auditing and a compliance pack list
Most infrastructure scanners are security tools with a cost plugin bolted on. Valqore's rule set is organised differently, spanning security, cost, carbon, compliance and AI governance across 1,431 built-in rules and 19 compliance packs, and the README is specific that no configuration is needed.
The GreenOps side is the least expected. It computes CO2 equivalent emissions per workload, suggests greener regions, tracks carbon budgets and GPU emissions, and covers 77 cloud regions with grid carbon intensity data. Carbon as a first-class rule category rather than an estimate you assemble elsewhere is a genuine differentiator for anyone with an emissions target.
`agent-audit` is the other distinctive command. It discovers AI agents already running in your manifests, cluster or cloud, scores each one's governance posture across five dimensions, rolls up a fleet verdict of GOVERNED, PARTIAL or UNGOVERNED, and exports the result as OSCAL. The README frames it as answering who governs the agents now governing your infrastructure, which is a real question once agent tooling becomes part of a deployment.
The 19 packs span security, privacy, financial and AI regulation: SOC 2, ISO 27001, PCI-DSS, HIPAA, FedRAMP, DORA, GDPR, NIST CSF, EU AI Act, EU CRA, ISO 42001, NIST AI RMF, SR 11-7, FDA SaMD, AI-FinOps, PQC migration, and the OWASP LLM, Agentic and MCP Top-10 lists. The v1.13.6 release states that every required rule in all 19 now maps to a named control enforced by test, which is what makes OSCAL evidence bundles complete rather than partial.
Two release notes are worth pulling out. `valqore evidence cra` groups Cyber Resilience Act readiness by enforcement wave, separating reporting obligations due 2026-09-11 from product requirements due 2027-12-11. And v1.13.6 adds serverless-container rule families for AWS ECS and Fargate and Azure Container Apps and ACI, alongside offline `valqore evaluate`.
Version numbers that disagree with each other
The README and the release history do not line up, and if you are pinning anything in CI this matters.
The three newest releases are v1.13.6 published 2026-08-17 at 01:13:15, v1.13.5 at 01:15:47, and v1.13.4 at 01:15:46, which is two releases published within about three minutes of each other, in the reverse of version order. The v1.13.6 notes also say the previous release published there was 1.12.1, so the 1.13.x line appears to have been pushed as a batch rather than shipped incrementally.
Against that, the supply chain section of the README gives its public-image example as `ghcr.io/valqore/engine:1.19.0`, and every cosign command in that section verifies `1.19.0`. There is no 1.19.0 release in this repository. Meanwhile the licensing section pins the AI image at `engine-ai:1.13.6`, which does match a release tag, and the quickstart pulls `:latest` with no version at all.
So there are three version references in play, `:latest` in the quickstart, `1.19.0` in the verification example, and `1.13.6` for the licensed image, and only the last one corresponds to a published release. The likeliest reading is that `1.19.0` is an error or a stale edit in the docs, but a reader following the verification instructions literally will get a tag that does not exist.
What to do with that is concrete. Pin your CI to an explicit engine tag rather than `:latest` so a pull is reproducible, and run the cosign verification against the tag you actually pinned instead of copying the version out of the README. The signature check is worth doing rather than assuming: images are keyless-signed in CI through Sigstore with GitHub OIDC and Rekor, the AI image is signed with the project's release key whose public half is committed as `cosign.pub`, and SBOM attestations are available through `cosign verify-attestation` with the `spdxjson` type.
The last push was on 2026-09-05, and the license field carries no recognised identifier, so the LICENSE file is the authority on what the repository text and images are under.
Editorial conclusion
Valqore is a reasonable thing to trial in CI, because the free image needs nothing but Docker, decides deterministically without a model in the loop, and signs its artefacts so you can verify what you pulled. Three things to settle first. The repository you would read holds no engine source: the listing is documentation, examples, whitepapers and blog posts, while every release note points at a separate `valqore-engine` repository, so auditing the rules means auditing the image or finding that other repository. The version references inside the README disagree with each other, with a cosign example naming image `1.19.0` while the newest release is `1.13.6`. And the AI features live behind a license key on a separate image. Start by running `valqore evaluate` on one manifest and reading the rule identifiers it emits, since whether those rules match your own policy is the only thing that decides this tool.
Frequently asked questions
What is Valqore and what does it scan?
Valqore is an infrastructure governance engine that scans Kubernetes manifests, Terraform configurations and cloud resources, then returns a score from 0 to 100 and a verdict of PASS, PASS_WITH_MONITORING or BLOCK. It ships 1,431 built-in rules covering security, cost, carbon, compliance and AI governance, grouped into 19 compliance packs, and needs no configuration file.
How do I run Valqore against my Kubernetes manifests?
Pull `ghcr.io/valqore/engine:latest` and run `valqore evaluate ./k8s/ --score` through the documented docker alias, or point it at one file with `valqore evaluate deploy.yaml --score`. For enforcement rather than reporting, `helm install` the `valqore-stack` OCI chart, which creates eight native `ValidatingAdmissionPolicy` objects the API server applies, with Valqore itself out of the request path.
Do I need a license key to use Valqore?
No for the deterministic core. The public `ghcr.io/valqore/engine` image is free and tokenless and includes all rules, scoring, drift detection, compliance and the MCP server. Only the AI features, meaning AI Scan and the chat surface built on an embedded offline model, require the licensed `engine-ai` image and a `valqore activate` key.
Where is Valqore's source code?
Not in this repository. GitHub reports Python as the primary language, yet the file listing holds documentation, examples, benchmarks and blog posts with no engine source. The release notes and the cosign identity examples point at a separate `valqore-engine` repository, and the README states the public image is compiled native code with no readable source.
How do I verify the Valqore container image is authentic?
Every published image is cosign-signed and carries an SPDX SBOM. The public image is keyless-signed through Sigstore using GitHub OIDC and Rekor, verifiable with `cosign verify` and `cosign verify-attestation --type spdxjson` plus the certificate identity regexp for the engine repository, while the AI image is signed with the project's release key whose public half is committed as `cosign.pub`.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/valqore-valqore)