Can open source replace JFrog Xray for container and package scanning?
For container images, Trivy inside Harbor covers static vulnerability analysis, and DefectDojo can track the resulting findings through deduplication, remediation and reporting. Curation and license-policy enforcement have no direct open-source match, so teams that rely on blocking packages before they enter the repository or on license gates in the build need a separate control plan. This page covers which JFrog Xray capabilities these open-source tools replace, which ones they only partly cover, and what the reader should confirm before a renewal decision.
JFrog Xray is typically entitled through a higher Artifactory tier or an add-on bundle, so a team that loses that entitlement, or wants to stop paying for it, still needs scanning of images and packages to continue. The replacement scope here is image scanning inside Harbor, which Harbor's documentation describes as enabled at install time with the --with-trivy option, and the findings workflow in DefectDojo, which exposes a REST API (API v2). Harbor bundles Trivy 0.75.0 in v2.15.4, so confirm the Trivy version your installed Harbor release uses before you compare results with Xray output.
Package scanning is the harder part. Pulp's vulnerability reporting is still in tech preview, so confirm its current status and format coverage for each plugin you host, and check whether the packages you need are covered by the plugins that are past version 1.0. Ask your JFrog account team for the exact Xray entitlements you use today, including any curation and license-policy rules, so the gap list reflects your estate rather than a generic feature comparison. A team that cannot list those rules yet should not sign a renewal or a migration plan.
Mapping Xray capabilities to open-source scanning options
This table maps each Xray capability to the open-source option that covers it, with a coverage level and the checks to run in your own environment. Read the coverage column first: most Xray functions have a partial match, and curation and cross-repository impact analysis have no direct open-source equivalent. Confirm each row against your formats and policy requirements before you remove Xray from the renewal plan.
| Xray capability | Open-source option and coverage | What to confirm in your environment |
|---|---|---|
| Image vulnerability scanning | Trivy inside Harbor, enabled with the --with-trivy install option. Strong coverage for OCI images through static analysis; Harbor can also connect to an external Trivy instance. | Confirm the Trivy vulnerability database update path works in air-gapped or egress-restricted networks, and check which image layers and OS packages your base images use. |
| Helm chart scanning | Partial. Harbor stores Helm charts as OCI artifacts, but Trivy's chart coverage is not a like-for-like match for Xray's chart inspection. Treat chart findings as a separate test. | Scan a sample of your production charts and compare results with your current Xray output before relying on Harbor alone. |
| Package scanning (Maven, npm, Python, RPM, Debian) | Partial. Pulp tech-preview vulnerability reports cover some plugins, while plugin maturity varies from past 1.0 to 0.x releases. Check each plugin's report output before assuming parity. | List every package format you scan today, then confirm which Pulp plugin provides it and whether its vulnerability report is enabled and tested. |
| Policy enforcement (block downloads or deployments) | Partial. Harbor can prevent pulls of images that exceed a severity threshold per project, but enforcement across package formats depends on a custom gate in CI or the admission controller. | Define the blocking rule in writing, then test that a vulnerable image is refused by Harbor and by your cluster admission path. |
| Watches and notifications | Partial. Harbor webhooks and scan events can notify external systems, and DefectDojo can receive findings for triage. Watches with the same scope as Xray need custom configuration. | Note that webhooks to internal network addresses are blocked by default in v2.15.3 and later, so confirm the notification target is allowed. |
| Reporting and findings tracking | Strong with DefectDojo, which deduplicates findings, tracks remediation and produces reports through its REST API (API v2). Harbor's own scan view covers per-image reporting. | Confirm how your auditors expect findings and remediation dates to be retained, and test the DefectDojo import for your scanner output. |
| Impact analysis across repositories | Gap. No direct open-source equivalent identifies every artifact and repository affected by a newly disclosed vulnerability. Partial workarounds use image digests and the referrers API to link scan results to images. | Decide whether your incident process needs cross-repository impact queries, and budget custom tooling or an Xray-equivalent workflow if it does. |
| Curation and license policy | Gap. Harbor and Pulp do not offer Xray-style curation that blocks packages by policy before they enter a repository, and no open-source option in this set matches its license compliance reporting. | Ask your legal and security teams which license and curation rules apply, then decide whether manual review or a separate policy engine will enforce them. |
Which scanning option fits which team
Harbor provides static vulnerability analysis of container images through the open-source Trivy scanner. Trivy is enabled at install time with the --with-trivy option, and Harbor can also connect to an external Trivy instance or other scanners. This fits platform teams who want every image pushed to a project to be scanned as it lands, with findings visible next to the artifact.
- Scan at push: Images are checked when they enter a Harbor project, so the scan result is attached to the exact digest the cluster will pull.
- Project-level policy: Projects can be configured to block pulls of images that exceed a severity threshold, which is the closest open-source match to a deployment gate.
- Bundled version: Harbor v2.15.4 bundles Trivy 0.75.0, so check the vulnerability database update path in an air-gapped network.
- Not covered: Harbor's scanner does not manage triage, ownership or risk acceptance, and it does not scan packages in Maven, npm or Python repositories.
- Operating cost: You run the scanner, keep its vulnerability database current and size its resources for peak push times.
Confirm with your Harbor version whether admission enforcement is configured through projects or through a separate Kubernetes admission controller in your environment.
DefectDojo describes itself as a DevSecOps and vulnerability management tool that orchestrates security testing, tracks findings, deduplicates them, and supports remediation and reporting. It does not scan images itself. It is the place where output from Trivy, Nessus, Qualys, Nexpose and other tools is gathered, so one team can see one list of open risk. This fits security teams with several scanners who need consistent triage and reporting.
- Multi-tool import: The REST API (API v2) and parsers for tools such as Tenable, Qualys VMDR and Nexpose let you combine infrastructure and application findings in one place.
- Deduplication: Each parser defines its own hash fields, such as title and severity for Tenable reports, so confirm the behavior for the parsers you rely on.
- Edition limits: The open-source edition, licensed BSD-3-Clause, uses local accounts. SSO with SAML, OIDC or OAuth, LDAP and MFA are DefectDojo Pro features.
- Not covered: DefectDojo does not replace a scanner or a registry, and it has no built-in image admission control.
- Operating cost: You run the Docker Compose stack, back up its database and write the import pipelines that feed it.
Confirm that the parsers you need exist in the version you deploy, and decide who owns severity changes and risk acceptance before the first import.
Pulp hosts Maven, npm, Python, RPM, Debian and other content, and it has been developing vulnerability reporting for Pulp-hosted content. The feature is still a tech preview, so it should be treated as something to evaluate, not as a production control. This fits teams that host their own packages in Pulp and want to see which hosted items are affected.
- Tech-preview status: Confirm the current preview scope, its limits and whether its interfaces may change before depending on it.
- Plugin maturity: pulp_rpm and pulp_python are past version 1.0, while pulp_maven and pulp_npm are still 0.x, so reporting coverage may differ by format.
- Container content: pulp_container syncs Cosign signatures stored as OCI images, but Harbor remains the stronger fit for image scanning at push.
- Not covered: Upstream public package advisories are not a substitute for the curation and license-policy checks Artifactory offers.
- Operating cost: You own the Pulp deployment, its PostgreSQL database and the time to validate the preview output against a known test set.
Ask Pulp maintainers or your own test results which formats the report covers today before you plan a control around it.
Most teams that replace Xray will combine tools rather than find one product that does everything. A common layering is Trivy inside Harbor for image gates, Pulp reporting for hosted packages, and DefectDojo as the single queue for triage. This model fits organizations with mixed estates, multiple teams and an audit need for a documented decision trail.
- Gate: Harbor blocks or flags images at push or pull time based on Trivy results.
- Package review: Pulp-hosted packages are checked through the preview reports and any other scanners you choose.
- Triage: DefectDojo collects findings, deduplicates them and records owners and due dates.
- Reporting: Export DefectDojo reports as evidence for internal reviews, which helps your compliance team prepare controls without making any assessment claim.
- Integration effort: Someone must write the pipelines and keep them working when any tool upgrades.
Before committing, map every Xray feature your teams use to one of these layers and list the gaps for your own risk owners to accept or fund.
Some JFrog Xray capabilities have no direct open-source match, and a page about replacement should say so plainly. Curation, which blocks packages before they enter a repository based on policy, and license-policy enforcement are the most common gaps. Teams in regulated environments often rely on these, so they need a decision before cutover, not after.
- Curation: Pre-download policy blocks have no direct equivalent in Harbor, Pulp or DefectDojo, so plan a manual or scripted review step.
- License compliance: Open-source scanners can report licenses in some modes, but a policy engine that enforces approved license lists must be built or sourced.
- Federated context: Xray's view across multiple Artifactory instances has no one-to-one replacement, so consolidate findings in DefectDojo.
- Support model: There is no vendor SLA for open-source components, so decide who you will call when a scanner fails.
- Budget line: Engineering time for building these controls is a recurring cost to set against subscription fees.
Ask your JFrog account team for the current tier feature matrix and compare it line by line with your own control requirements.
How Trivy scanning runs inside Harbor
Harbor performs static vulnerability analysis of container images through the open-source Trivy scanner, but only if you enable it. Trivy is not part of a default install: you turn it on with the --with-trivy option when you run the Harbor installer. Harbor can also connect to an external Trivy instance or to other scanners, which matters if your security team already runs a scanning service or needs scanning outside the registry host. Harbor v2.15.4, the current stable release, bundles Trivy 0.75.0, so confirm that version in your own deployment before you write it into a control narrative, because a later Harbor patch may change the bundled version.
A scan produces a per-image report of vulnerabilities found in OS packages and language dependencies, with severity and fix status for each finding, attached to the image in the Harbor UI and available through the REST API. Those results are what you will later feed into DefectDojo or another tracker, so check the report fields your tracker needs before you design the pipeline. Confirm three things with your platform team: when scans run (on push, on a schedule, or only when someone triggers them manually), whether a project can block pulls of images that exceed a severity threshold, and how the Trivy vulnerability database is refreshed. If the registry sits in an air-gapped network, the database update path must be planned in advance, because a scanner with stale data reports a false sense of coverage.
Where Xray features have no direct open-source match
Harbor with Trivy and DefectDojo covers image scanning and finding tracking, but several Xray capabilities have no single open-source counterpart. The cards below cover each gap, the workaround that exists today, and the engineering and process work that workaround adds to your team's load.
Package curation before download
Curation in JFrog blocks or approves packages before they reach developers, based on policy. Harbor's proxy cache serves upstream images on request and does not evaluate them against a policy first, so you must add that gate yourself. Common workarounds are an allowlist of approved repositories and tags enforced through Harbor project settings, or a Pulp remote that syncs only chosen content. Each approval list needs an owner, a review cadence and a process for emergency additions. Confirm the exact enforcement points with each platform's documentation before you commit to a design.
License-policy enforcement
Xray can evaluate license obligations across packages and block or warn on disallowed licenses. Harbor's Trivy scanning focuses on vulnerabilities and misconfigurations in images, so license checks are not a native Harbor feature. Teams typically add a separate license scanner in CI or run an SBOM-based tool against images that Harbor stores. Expect to define an approved license list with legal, map license names across ecosystems, and handle exceptions in a written register. Ask any scanner vendor or project which license data sources it uses and how it treats ambiguous or missing license fields.
Impact analysis across dependency graphs
When a new advisory lands, Xray can show which artifacts, builds and deployed components depend on the affected package. Open-source setups usually rebuild this view from SBOMs attached to images, using the referrers API defined by the OCI Distribution Specification to find them, and from the build metadata in your CI system. The work is to generate SBOMs for every build, store them consistently, and write queries that connect package versions to running workloads. Without that inventory, impact analysis becomes a manual search across repositories and clusters.
Watches and notifications
Xray watches let you subscribe to specific repositories or components and receive alerts when new violations appear. The closest open-source pattern combines Harbor webhooks, scheduled rescans and DefectDojo imports, which can notify teams when new findings are created. Harbor v2.15.3 blocks webhooks to internal network addresses by default, so confirm the destination settings before you rely on them. Plan who receives each alert, how duplicates are suppressed, and how you test that a notification reaches the right queue.
Vendor-maintained vulnerability feeds
JFrog maintains its own vulnerability data and curated feeds for Xray. Trivy pulls vulnerability databases published by its maintainers, and DefectDojo aggregates findings from whichever tools you run. No single open-source feed carries the same vendor-side triage and support as a commercial feed, so you take on the responsibility for feed freshness, air-gapped updates and reconciling conflicting severity ratings. Document which databases you trust, how often they update in your network, and who decides when a finding is a false positive.
Enterprise support for scanner accuracy
A commercial subscription gives you a vendor to contact when a scan misses a vulnerability or reports a false positive. Open-source scanners are supported by their communities and by any commercial partner you engage separately. Your team should test scanners against known-vulnerable images, track accuracy over time, and set an internal escalation path for scanner defects. Ask any support provider you consider which versions they cover, what response commitments they offer in writing, and how they handle issues in upstream projects.
Questions teams ask before replacing Xray
What does it cost to replace Xray with open-source scanning?
The software itself is free under the open-source licenses, so the cost is the work and the infrastructure: installing and hardening Harbor with Trivy, wiring findings into DefectDojo, staffing the upkeep and running the scanner's database updates. Harbor, Trivy and DefectDojo Open Source are one-time setup and recurring operations, while JFrog's Xray price depends on the subscription tier and any add-ons you hold. Ask any quote to split one-time setup from recurring operations, and to list which Xray features (curation, license policy, deeper component analysis) are excluded and how each gap is handled.
How long does a migration from Xray to Trivy and DefectDojo take?
Duration depends on how many repositories and pipelines feed findings today, how many policies must be recreated, and how much your teams already use DefectDojo. A scoped first phase usually covers scanning in Harbor for a limited set of projects, then expands. No duration figure is supplied for this work, so ask any implementer for a written timeline tied to the agreed scope before work starts, including the points where your security team signs off on findings handling.
What does the work require from our own team?
Plan for at least one platform engineer who owns Harbor, one person who owns the vulnerability workflow in DefectDojo, and security staff who define triage rules and severity thresholds. Your CI owners must change the pipeline steps that call scanners and read results. Keep the list of Harbor install options and upgrade notes in view, because recent minor releases changed the bundled database and cache and added breaking webhook and content trust behavior, so upgrades need a rehearsal and a backup.
Can our team do this migration without outside help?
Yes, if you already run Kubernetes or Docker Compose services, operate a PostgreSQL database and have engineers comfortable with registry authentication and CI credentials. The harder parts are policy design, integrating scanner output into DefectDojo parsers and documenting evidence for auditors. Teams without that experience often hire help for the first cutover and then run the platform themselves. DeployOpen plans, implements, integrates, hardens and documents self-hosted platforms in your own infrastructure under a written scope, and offers retainers for ongoing support.
How does Trivy compare with Xray coverage?
Harbor provides static vulnerability analysis of images through Trivy, which you enable at install time with the --with-trivy option, and it can also connect to an external Trivy instance or other scanners. Trivy covers the image contents used in your registry, but it is not a one-to-one match for Xray. Xray features such as curation, deeper component and violation tracking across JFrog repositories, and its license policy engine have no direct open-source match. Map each Xray report you rely on to a Trivy output or a DefectDojo workflow, and test the mapping on real images before you retire Xray.
How do we handle license policy without Xray?
License policy is the Xray area with the weakest open-source match in this migration. Trivy and DefectDojo track vulnerabilities and findings, but they do not replace a license compliance engine that enforces allow and deny lists across all package types. Decide whether license checks move to a separate open-source tool in your pipeline, become a manual review step owned by legal or compliance, or stay on Xray for a transition period. Write that decision down with an owner before cutover, since it affects your evidence for licensing controls.
When is it worth hiring a partner for the migration?
Bring in a partner when the migration touches regulated evidence, multiple registries or air-gapped networks, or when your team lacks capacity for the parallel run. A partner is also useful for hardening Harbor, documenting controls for an assessment and running security testing of the new pipeline. DeployOpen works from a fixed scope agreed in writing, and does not issue audit reports or certifications, which remain the job of independent auditors. Ask for a written scope, named deliverables and a retainer option for upgrades before you sign.
What the Xray replacement costs to run
The recurring commercial line for Xray is the subscription tier or add-on that includes it, and that line is set by JFrog's contract rather than by anything in this page. Ask your JFrog account team in writing which tier includes Xray, whether it is bundled or priced separately, and how it scales with your artifact volume or server count. On the open-source side, the recurring costs are the servers and storage for Trivy scanning inside Harbor, the database and backups for DefectDojo, the time spent keeping scanner data and container images current, and the engineering hours that go into triage. DefectDojo's open-source edition uses local accounts. SSO with SAML, OIDC or OAuth, LDAP and MFA are listed by DefectDojo as Pro features, which the DefectDojo README says start from $100 per month. Treat that as a separate, recurring line if your identity policy requires any of those controls, and confirm current pricing with DefectDojo before you budget.
Some costs are one-time and some recur, and the split matters for the business case. One-time work includes designing the scan flow between Harbor, Trivy and DefectDojo, defining severity thresholds and the policy that blocks or flags deployments, importing historical findings, and migrating existing Xray policies and exceptions. Recurring work includes upgrading Harbor (where the v2.15.2 release notes recommend a backup before upgrading), upgrading DefectDojo, patching the hosts and databases, keeping Trivy's vulnerability data fresh in air-gapped environments, and triaging new findings each week. Your team's time usually drives the total more than licence fees do, so ask any implementation partner for a fixed-scope estimate that separates build effort from ongoing operations. DeployOpen works from a written scope, so request the same breakdown from any firm you compare.
When you request quotes, ask for each component to be priced separately: the Xray tier or add-on for the commercial side, and for the open-source side, the infrastructure you will run, the DefectDojo edition and any Pro features you need, the upgrade and patch cadence, support hours, and the work needed to replace curation and license-policy controls that have no direct open-source match. Ask the vendor which features, such as curation or federation, must be budgeted as custom work or third-party tooling. Ask whether the quote includes handover documentation and who holds the runbooks after the project ends. A comparison built this way shows where the real spend sits, which is often in people rather than software.
Moving scanning and findings to open source
This sequence moves image scanning, findings tracking and release gates from Xray to Trivy in Harbor and DefectDojo, with each step closing on a check you can verify before the next one starts. It also flags which Xray-dependent reports and approvals need an owner before cutover.
Inventory Xray policies, watches and reports
Platform or security engineering lists every Xray policy, watch, report and approval rule in use, including which repositories each watch covers, which severity thresholds block downloads or builds, and who receives each report. Record which items depend on Xray-only features such as license policies, curation or contextual analysis, since these have no direct open-source match. The step is done when every item has an owner and a status of replace, rebuild or retire.
Enable Trivy scanning in a Harbor test project
Platform engineers install a test Harbor instance with the --with-trivy option, or point Harbor at an external Trivy instance, then create a test project with automatic scan on push enabled. They push a set of representative images from the current build pipeline and confirm that scan results appear on each artifact. The step closes when scans complete on every test image and the Trivy version reported matches the bundled release you intend to run.
Compare findings against Xray on sample images
Security engineers select a sample of images that cover the main base images and language stacks in use, then compare the Trivy findings with the Xray results for the same digests. They record differences in CVE coverage, severity assignment, fixed-version data and false positives, and note which differences need a documented acceptance decision. The step is done when the comparison is signed off by the security lead, with each gap either accepted or assigned a remediation.
Set up DefectDojo for findings tracking
Security operations deploys the open-source edition of DefectDojo with Docker Compose, creates products and engagements that match the application or platform ownership model, and configures local accounts with role-based access for developers and reviewers. Note that SSO with SAML, OIDC or OAuth, LDAP and MFA are Pro features, so confirm whether local accounts meet your identity requirements before going further. The step is done when a test product exists, users can log in and the API is reachable with a service token.
Import scanner output into DefectDojo
Engineers configure the CI job to export Trivy results in a format DefectDojo can parse, upload them to the matching engagement through the REST API v2, and confirm that deduplication groups repeated findings across builds. Where Xray reports were used for other sources, confirm which parser covers each feed, since parser coverage varies by tool and format. The step closes when a test build creates findings, a second build with the same CVE updates rather than duplicates them and the import log shows no parser errors.
Define replacement policy gates
Security and platform leads write the gate rules that replace Xray blocks, such as which severities fail a build, how exceptions are approved and how long a finding can remain open with an accepted risk. Document how each rule is enforced: in the CI pipeline, in Harbor project settings that prevent pulls of unscanned or vulnerable images, or in admission controls for the cluster. Approve the rules in writing with the owners named in step one. The step is done when every gate has a written rule, an enforcement point and an exception owner.
Cut over CI and admission checks
Platform engineers switch CI jobs and cluster admission checks from Xray queries to the Harbor and DefectDojo gates, run both paths in parallel for a short observation window agreed with the owners, and then disable the Xray watches. Confirm which reports and approvals still depend on Xray features with no match, and assign each a documented replacement or an accepted gap before the Xray subscription is changed. The step is done when a build blocked by a critical finding fails in the new pipeline, the owners confirm the reports they rely on and the Xray watches are removed from production.
Running Trivy and DefectDojo alongside JFrog Artifactory
These four cards cover the transition period, when Artifactory keeps serving content and Xray keeps enforcing policy while Harbor and DefectDojo are checked against them. Each step keeps a working path open, so the team can compare results before anything is switched off.
Keep Artifactory as the source
During transition, Artifactory stays the place where builds push and pull images and Helm charts. Harbor reaches into it through a replication endpoint, so the source of truth does not move on day one. Create a pull-based replication rule limited to the repositories in scope, and confirm that the Artifactory service account can read every project the rule covers. Check tag filters too, because a rule that misses a tag leaves Harbor scanning an incomplete set.
Scan replicated copies in Harbor
Once content is replicated, Harbor runs Trivy against the images it holds, so the team sees findings without changing how developers pull images. Trivy is enabled at install with the --with-trivy option, or Harbor can connect to an external Trivy instance. Compare the scan result for each digest against Xray's result for the same digest, since differences in advisory sources and scan timing explain most early surprises. Confirm which Trivy version your Harbor release bundles before you rely on its default database behavior.
Run parallel findings in DefectDojo
DefectDojo gives both scanners one place to be triaged, deduplicated and reported. Import the Xray findings and the Trivy results into the same product so the team can see where the two agree and where they diverge. Confirm that your Trivy output format has a supported DefectDojo parser in the current supported tools list, because a missing parser means a custom import step to maintain. Assign an owner and a due date to each finding, so the comparison measures triage effort rather than only finding counts.
Keep Xray until policies are proven
Xray enforces blocking and policy decisions in Artifactory today, so it should stay active until the replacement produces the same outcomes. Map each Xray policy and watch to the closest Harbor control or to a CI gate, and record every gap in writing. Curation and license-policy features have no direct open-source match, so each of those gaps needs a named owner and a compensating control before Xray is switched off. Review parallel results over several release cycles before making that decision.
When keeping Xray is the better decision
Keep Xray if your organization depends on JFrog's curation or on license compliance reporting that auditors accept as evidence. Harbor scans images with Trivy and DefectDojo tracks findings, but neither gives you a pre-download curation gate that blocks components by policy, and the supplied facts do not establish an open-source equivalent that enforces license-policy decisions across all package formats. If your change approval or audit process requires a vendor-produced license report for every binary you ship, that requirement alone may outweigh the cost savings. Confirm with JFrog exactly which Xray and curation features your current subscription tier and add-ons include, because the answer depends on your contract, not on the product name.
Support requirements are the second reason to stay. If your policy requires a named commercial vendor with contractual response commitments for a security tool, a self-hosted stack assembled from Harbor, Trivy and DefectDojo moves that responsibility to you or to a services partner. Ask your procurement and risk teams whether they accept community support plus a fixed-scope implementation agreement, or whether they need a vendor SLA in the contract. Also check what your regulators and auditors expect for vulnerability management and software supply chain evidence, since the mapping of those expectations to tools is a policy decision for your organization.
The decision belongs to your own policy and audit requirements, and it should be written down before any migration work starts. DeployOpen can help you define the controls, configure the scanning and ticketing workflow in your environment, and collect the evidence those controls produce. DeployOpen does not issue audit reports, attestations or certifications, so independent auditors and certification bodies remain responsible for any formal assessment. A practical step is to list every Xray feature your teams use, mark each as replaced, partly replaced or required, and bring that list to your auditors before you decide.
How DeployOpen scopes and delivers scanning replacement
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so scanning for images and packages runs where your registries run. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- We inventory which images, Helm charts and packages currently pass through Xray and which findings your teams act on.
- The written scope names the Harbor projects, Trivy configuration, DefectDojo instance and any Pulp repositories included.
- We confirm with you which Xray features, such as curation or license policies, are excluded and how each gap will be handled.
How we build
- We install Harbor with Trivy enabled, or connect an external Trivy instance, inside your cloud accounts, data centers or air-gapped network.
- We configure DefectDojo, import scanner output through its parsers and set deduplication and remediation workflows.
- We test scanning results against known vulnerable test images and confirm alerts, access control and audit logs behave as specified.
How we hand over
- You receive configuration records, runbooks for triage and a written map of each Xray feature to its replacement or accepted gap.
- We document the evidence that supports your internal controls, while noting that independent auditors and certification bodies issue any formal assessment.
- Knowledge transfer sessions cover how your security team reviews findings, upgrades Harbor and maintains DefectDojo over time.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover Harbor and DefectDojo upgrades, including checks of breaking changes listed in each release before rollout.
- Ask any provider for the support hours, response commitments and upgrade cadence in writing before you sign.

