Scan Oracle Cloud DevOps Repositories and OCIR Images with Safeguard

To scan the code and container images you keep in Oracle Cloud Infrastructure, give a dedicated OCI user two narrow, read-only policies: read devops-family for the DevOps code repositories and read repos for Container Registry (OCIR). Point your scanner at both with that user's auth token or API signing key, pin every image scan to a digest, and rescan on push or on a schedule. The source and the image then produce two SBOMs you can compare, and a gate decides what may ship.

That is the short answer. The rest of this post is the long one: what goes wrong when OCI teams scan only one of the two, the exact Oracle policy statements and username formats that trip people up, a same-day checklist that works with any tooling, and then the Safeguard flow for both cards, step by step, with the limits stated plainly.

Key takeaways

• OCI DevOps code repositories and OCIR images are two different services with two different policy families: devops-family (and devops-repository) for code, repos for images. Scanning one does not cover the other.
• Least privilege for a scanner is read devops-family for code and read repos for images. Oracle's own docs show that inspect repos lists repositories but does not let you pull.
• The username for both auth-token flows is built from the tenancy, not your email. DevOps Git over HTTPS uses the tenancy name; OCIR uses the Object Storage namespace. Mixing them up is the most common setup failure.
• Safeguard's Oracle Cloud DevOps integration (GA) lists your DevOps projects and code repositories, scans each selected branch or tag for an SBOM and findings, and can rescan on push through OCI Events and Notifications.
• Safeguard's Oracle Container Registry (OCIR) integration (GA) lists your repositories and tags, pins each scan to the digest the tag pointed at when the scan started, and only ever reads.
• SBOM generation and analysis (GA), SCA and vulnerability management with EPSS and KEV (GA) and reachability analysis and prioritisation (GA) run on every project the two cards create.
• Policies and gates (GA) decide the outcome. Each policy's action is Block, Warn or Notify, and approval for a known risk runs through exceptions.
• Autonomous remediation with Griffin fix pull requests (GA) can open fix pull requests on OCI DevOps repositories when the connection has an API signing key and the optional manage devops-repository policy. It ships switched off, with every category set to Manual.
• The Safeguard CLI (GA) can scan an image inside a pipeline step and fail the job on a severity or on a gate.

The situation

You run on Oracle Cloud. Your application code lives in OCI DevOps code repositories, inside one or more DevOps projects. A build pipeline turns that code into a container image and pushes it to Container Registry in the same region. Kubernetes Engine (OKE) or a container instance pulls the image from there.

Then a request lands. It might be a customer security questionnaire asking for an SBOM of what you ship. It might be an internal audit that wants proof that every production image was scanned before release. It might be a new critical advisory in a library you are fairly sure you use, and someone senior asks, "Which of our images carry it, and which repositories do we fix?"

The bad week looks like this:

• Somebody scans the source repositories with a tool that reads lockfiles, and reports "clean". Nobody scanned the base image, the operating system packages or the binaries a Dockerfile copied in, and those are where the advisory sits.
• Somebody else scans the images in the registry by tag. Between the scan and the deploy, the latest tag moved. The SBOM you hand the customer describes an image that is no longer running.
• The scanner was set up months ago with an engineer's own auth token. The engineer has left, the token was deleted with their account, and every scan since then has quietly failed.
• The scanner's user was given manage on the whole tenancy "to make it work", so a credential that only needed to read now has the power to push images and delete repositories.

None of this is exotic. It comes from treating "scan our Oracle Cloud estate" as one job, when on OCI it is two services, two policy families, two username formats and two different kinds of artifact.

Two services, two kinds of artifact

It helps to be precise about what each service holds, because the scanning approach differs.

OCI DevOps code repositories. Oracle describes the DevOps service as an end-to-end CI/CD platform that, among other things, provides private Git repositories to store your code. Each code repository sits inside a DevOps project, and each project sits in a compartment. You clone them over HTTPS (with an auth token) or SSH. What a scanner reads here is source: manifests, lockfiles, vendored code and build files at a branch or tag.

OCI Container Registry (OCIR). Oracle describes Container Registry as an Oracle-managed registry for storing, sharing and managing container images, and states that it is Open Container Initiative compliant. Clients push and pull with the Docker V2 API and the standard Docker CLI. Repositories can be private or public. What a scanner reads here is the built artifact: image layers, the packages installed in them, language runtimes, and whatever the build copied in.

The source scan tells you what your code declares. The image scan tells you what you actually ship. You need both, and you need them tied together, because a fix lands in the repository but the risk lives in the image.

The rules behind it

No regulation names OCI DevOps or OCIR. The obligations come from general secure development and container guidance, and they map cleanly onto the two services.

NIST SP 800-218, the Secure Software Development Framework (SSDF) version 1.1. NIST describes the SSDF as a core set of high-level secure software development practices that can be integrated into any software development life cycle, with the stated aim of reducing vulnerabilities in released software and limiting the impact of those that slip through. It also notes that buyers can use the same vocabulary when talking to suppliers. For an OCI team, that means a customer or auditor will ask you to show, in SSDF terms, that you know what is in each release and that you find and fix vulnerabilities in it. Two scans, source and image, with retained results, are the evidence.

NIST SP 800-190, the Application Container Security Guide. NIST explains that containers combine operating system virtualisation with application packaging, and that the publication sets out the security concerns that come with them and recommendations for each. Image vulnerabilities, and the risk of running images whose contents nobody has checked, are central to that guidance. A registry full of images that were never scanned, or scanned once by tag and never again, is exactly what it warns against.

The OCI Distribution Specification. This is not a regulation, but it is the rule that makes image scanning reproducible. The specification defines a digest as a unique identifier created from a cryptographic hash of a blob's content, and a tag as a human-readable pointer to a manifest; a manifest digest can have zero, one or many tags pointing at it. Tags move. Digests do not. If your evidence names a tag, it is evidence about whatever the tag pointed at that day.

Oracle's IAM model. Oracle's DevOps and Container Registry policy pages are where least privilege is actually defined. They are vendor documentation, not law, but an auditor checking access control will compare your scanner's policy statements against them.

Step by step, with or without Safeguard

This part works with any scanner, including a home-grown one. Do it in this order.

1. Inventory what you have

List the DevOps projects and their code repositories per region and compartment, and list the Container Registry repositories per region. Write down, for each image repository, which code repository builds it. That mapping is the thing most teams do not have, and it is what turns "this image is vulnerable" into "fix it in this repository".

A simple table is enough to start:

2. Create a dedicated scanning identity

Create one IAM user for the scanner and one group for it. Do not reuse a person's account. Oracle's own guidance on auth tokens notes that each user can hold at most two auth tokens at a time, which is handy: it lets you rotate by creating the second token, switching over, then deleting the first.

3. Write the narrowest policies that work

For DevOps code repositories, Oracle's DevOps IAM page explains that devops-family is an aggregate: a policy on devops-family with a given verb equals a separate statement for each DevOps resource type. The verbs are inspect, read, use and manage. For a scanner that lists projects, reads refs and clones, the starting point is:

Allow group scanner-readers to read devops-family in compartment app-compartment

Some tenancies refuse an HTTPS clone with only read. Safeguard's Oracle DevOps docs point out that Oracle documents use devops-repository (with project read access) as the policy for cloning. If a clone fails with a policy error, add this, and nothing more:

Allow group scanner-readers to use devops-repository in compartment app-compartment

For Container Registry, Oracle's repository access examples use inspect repos to list, read repos to pull, and manage repos to push and administer. A scanner must pull, so it needs read:

Allow group scanner-readers to read repos in compartment app-compartment

Oracle also shows how to narrow read repos to repositories whose names match a pattern, with a condition on target.repo.name. If one team's images are all the scanner should see, use it:

Allow group scanner-readers to read repos in compartment app-compartment where all { target.repo.name=/team-app*/ }

What the scanner should never hold: manage devops-family, manage repos, any Identity permission, or Object Storage access. If something asks for them, find out why before you grant them.

4. Get the username right

This is where most setups fail, because the two services build the username differently.

Oracle's HTTPS authorisation page for DevOps code repositories gives the tenancy-name formats, with the auth token as the password. Oracle's Docker CLI page for Container Registry gives the namespace formats, and notes that in some older tenancies the namespace happens to equal the tenancy name in lower case, which is why the mistake is easy to make and hard to spot.

The auth token is the password in both cases. The Console sign-in password does not work for either.

5. Pin images by digest

Whatever you scan with, record the digest of every image you scan, and tie your evidence to the digest. When the deploy manifest references a tag, resolve the tag to a digest at deploy time and compare it with the digest you scanned. If they differ, the scan is not evidence for what is running.

6. Decide when to rescan

There are three useful triggers:

• On push to the code repository. OCI DevOps emits events when a repository receives a push. Oracle's DevOps events page lists them, including HTTP Receive Pack (com.oraclecloud.devopscoderepo.httpreceivepack) and SSH Receive Pack (com.oraclecloud.devopscoderepo.sshreceivepack). An Events rule on those types, sent to a Notifications topic, can call your scanner.
• On build. Scan the image in the pipeline, right after it is built and before it is pushed or deployed.
• On a schedule. New advisories arrive every day for code that has not changed. A nightly or weekly rescan of every repository and every deployed image catches them.

7. Write the gate rule down before you need it

Agree, in writing, what blocks a release, what only warns, and who can approve an exception and for how long. A gate nobody agreed to gets switched off the first time it blocks a hotfix.

A same-day checklist

Which credential should the scanner use?

OCI offers several credential types, and the two services accept different ones.

Oracle's API signing key page explains the key pair model: an RSA key pair in PEM format of at least 2048 bits, with the public key uploaded to the user and the key identified by its fingerprint together with the tenancy and user OCIDs. Oracle also suggests appending an OCI_API_KEY label line to the private key so it can warn you if the key is ever committed to a public repository.

The practical answer for a scanner that covers both services: one dedicated user, with both an API signing key (for listing) and an auth token (for Git clone and image pull).

Should you scan the repository, the image, or both?

Both, for different reasons.

The repository scan is where the fix happens; the image scan is where the risk is measured.

How do push triggers work on OCI DevOps?

OCI DevOps does not use the webhook model that some Git hosts use. Instead, the code repository emits events into the OCI Events service. You create a rule that matches the event types you care about, and the rule's action sends the event to a Notifications topic. A subscription on that topic forwards the message to an endpoint. For a scanner hosted outside your tenancy, the subscription uses the HTTPS (Custom URL) protocol.

Two practical points:

• The person who creates the Events rule and the Notifications topic needs permission to manage them in the compartment. The scanner's identity does not.
• The subscription URL is a credential. Store it like a password.

How Safeguard does this

Safeguard has a card for each service under Integrations, on the Project/Product tab: Oracle Cloud DevOps for code repositories and Oracle Container Registry (OCIR) for images. Both are GA. Safeguard's docs say both cards are switched on per workspace, so if you do not see one, ask your Safeguard contact to turn it on. Both support only commercial OCI regions; government and sovereign OCI clouds are not supported yet.

Each repository or image you select becomes a Safeguard project with an SBOM and findings, so everything after the connection (SBOM generation and analysis (GA), SCA and vulnerability management with EPSS and KEV (GA), reachability analysis and prioritisation (GA), policies and gates (GA)) works the same way it does for any other source.

Part one: connect OCI DevOps code repositories

The Oracle Cloud DevOps integration (GA) connects to code repositories in OCI DevOps projects. It is always a private connection: Oracle does not offer anonymous read access to code repositories, so there is no public option.

1. Choose a sign-in method. The dialog offers three, all belonging to one OCI user, ideally a dedicated integration user in its own group.

2. Grant the policies. Safeguard's docs state that it calls only the OCI DevOps service (and Git over HTTPS on it), and no Object Storage, Identity or other OCI service. Put the integration user in a group (the docs call it safeguard-readers) and give the group these statements. Use in tenancy instead of in compartment when you leave the Compartment OCID empty.

Without the manage devops-repository statement, scanning works and only fix pull requests fail, with a message naming the missing policy. The docs list what Safeguard never needs: manage devops-family, any Identity, Object Storage or networking permission, or manage devops-repository when you only scan.

3. Create the credentials. The docs give both a Console path and an OCI CLI path. The CLI path, exactly as the docs show it (we did not run it for this post):

# Group, user and policy (run as an administrator)
oci iam group create --name safeguard-readers --description "Safeguard scanning"
oci iam user create --name safeguard-scan --description "Safeguard scanning"
oci iam group add-user --group-id <group-ocid> --user-id <user-ocid>
oci iam policy create --compartment-id <compartment-ocid> --name safeguard-devops \
  --description "Safeguard reads DevOps code repositories" \
  --statements '["Allow group safeguard-readers to read devops-family in compartment <compartment-name>"]'
# Auth token for the user (the token is printed once)
oci iam auth-token create --user-id <user-ocid> --description safeguard
# API signing key: create a key pair, then upload the public key
openssl genrsa -out safeguard_api_key.pem 2048
openssl rsa -pubout -in safeguard_api_key.pem -out safeguard_api_key_public.pem
oci iam user api-key upload --user-id <user-ocid> --key-file safeguard_api_key_public.pem

In the Console, the auth token is under the user's settings, on Tokens and keys, in Auth Tokens, with Generate token. Oracle shows it once. The API key is under API Keys, with Add API Key and Download Private Key; the Configuration File Preview shows the tenancy OCID, user OCID and fingerprint you need.

4. Use the right username. The docs repeat Oracle's rule: the username is built from the tenancy name, not your email and not the Object Storage namespace.

5. Connect it in Safeguard.

1. Open Integrations and choose the Project/Product tab.
2. Click Connect on the Oracle Cloud DevOps card. The connection is always Private.
3. Enter a Name (and an optional Description) and choose the Region.
4. Choose a Sign-in method and fill in its fields. For an auth token: Username and Auth token. For an API signing key: Tenancy OCID, User OCID, Key fingerprint, Private key (PEM) (or Choose a .pem file) and, if the key has one, Key passphrase.
5. Optionally enter the Compartment OCID (empty means the root compartment), Repositories by URL (one HTTPS clone URL per line, required with an auth token alone) or DevOps projects (one project OCID per line).
6. Click Verify Credentials. "Credentials verified." with the repositories visible means Oracle accepted them.
7. Click Next, select the repositories and the branch or tag of each, and finish with Connect, choosing a fast, deep or progressive scan.

Each selected repository is scanned when you connect it. You can set a schedule under Integrations > Scheduled, and scheduled rescans work whether or not you set up a push trigger.

6. Turn on scan on push (optional). After the connection is created, the dialog (and the Update dialog later) shows a Scan on push (optional) panel with a Subscription URL (HTTPS, Custom URL), a Username and Secret, and the event types for the Events rule. Then, in the OCI Console:

1. Open Notifications > Topics, create a topic, and create a subscription on it with protocol HTTPS (Custom URL). Paste the Subscription URL from the panel; it already carries the username and secret.
2. Safeguard confirms the subscription itself when the first message arrives.
3. Open Events Service > Rules and create a rule for the service DevOps with the event types HTTP Receive Pack (com.oraclecloud.devopscoderepo.httpreceivepack) and SSH Receive Pack (com.oraclecloud.devopscoderepo.sshreceivepack), with the topic as its action.

A push to a repository the connection scans then rescans it on its configured branch. The person creating the rule needs manage ons-topics and manage cloudevents-rules in the compartment; Safeguard's integration user needs nothing extra. Treat the secret like a password: anyone who has it can start rescans on the connection.

7. What Safeguard reads and stores. Per the docs, it reads DevOps projects and code repositories in the compartment (or the ones you listed), their branches and tags, and the contents of each selected repository at the chosen branch or tag; for fix pull requests, the repository's pull requests; and from push triggers, the push event. It stores the connection settings, region and compartment, the repositories you selected, the SBOM and findings of each scan, and the credentials, encrypted at rest with a per-workspace key and never shown again after you save them. It does not store source code: the scanner clones into a temporary folder and deletes it when the scan ends. The docs also state that no customer data from this integration is sent to third-party LLMs.

Part two: connect OCIR images

The Oracle Container Registry (OCIR) integration (GA) connects to images in Container Registry. Only commercial (oc1) regions are supported.

1. Public or private. For a public repository, choose Public and paste an Image URL, such as ap-mumbai-1.ocir.io/<namespace>/<repository>:<tag>. No credential is needed, but the repository must be marked public in OCI. For anything else, choose Private, pick the Region and a sign-in method.

2. Choose a sign-in method.

3. Grant one policy. For either method, the docs require one statement:

Allow group <group> to read repos in tenancy

or the same scoped in compartment <compartment>. The docs say plainly that inspect repos is not enough: it lists repositories but cannot pull images. Least privilege, per the docs, is a dedicated user in a dedicated group with read repos in only the compartment that holds the images, optionally narrowed with a condition such as where all { target.repo.name=/team-app*/ }.

Safeguard only reads. Per the docs, it never pushes, deletes or retags images, and calls no other Oracle service. It never needs manage repos, use repos, Object Storage, Identity or any other service's permissions.

4. Create the credential. The docs' CLI path, as shown there (not run for this post):

oci iam group create --name safeguard-ocir --description "Safeguard OCIR read"
oci iam policy create --compartment-id <tenancy-ocid> --name safeguard-ocir \
  --description "Safeguard read access to OCIR" \
  --statements '["Allow group safeguard-ocir to read repos in tenancy"]'
oci iam auth-token create --user-id <user-ocid> --description safeguard
# Check it:
docker login <region-key>.ocir.io -u '<tenancy-namespace>/<user>'

Note the username here: for OCIR it is <tenancy namespace>/<user> (or with the identity domain in the middle), and the namespace comes from Tenancy details > Object storage namespace. That is the opposite of the DevOps card, which wants the tenancy name. If you run both cards with the same integration user, you will type two different usernames for the same person.

5. Connect it in Safeguard.

1. Open Integrations and choose the Project/Product tab.
2. Click Connect on the Oracle Container Registry (OCIR) card.
3. For private images, choose Private, enter a Name, pick the Region (identifier or key, such as ap-mumbai-1 or bom) and the Sign-in method. With an auth token, the Tenancy namespace fills in from the username. With an API signing key, add the Compartment OCID if needed.
4. Optionally list Images (one per line) to connect only those.
5. Click Verify Credentials. "Credentials verified." means OCI accepted them, with the repositories visible.
6. Click Next, select repositories and tags, review, and choose fast, progressive or deep scan.

6. Digest pinning. The docs state that scans pull with your credential and are pinned to the image digest the tag points at when the scan starts, and that Safeguard stores the SBOM and findings of each scanned image with its digest. That is the property the OCI Distribution Specification makes possible, and it is what lets you match a scan to what is running.

7. Rescans. The OCIR card has no webhooks. Each selected image is scanned when you connect it. To rescan new tags, set a schedule under Integrations > Scheduled, or rescan by hand from the project.

8. What Safeguard reads and stores. Per the docs, it reads repository names, image tags and manifest digests, and the images you select. It stores the connection settings, the SBOM and findings of each scanned image with its digest, and the credential, encrypted at rest and never shown again. It does not store image layers: the image is read for the scan and not kept. No customer data from this integration is sent to third-party LLMs.

Why not the generic OCI Registry card?

Safeguard also has a generic OCI Registry card for any registry that speaks the Open Container Initiative distribution API. Its own docs say that registries with a dedicated card, Oracle Container Registry among them, work better through that card. The generic card's docs also note that its image pull does not use the stored credential yet, so a private image the scanner cannot pull is reported as a failed scan. For OCIR, use the OCIR card.

Part three: scan the image in the pipeline

The two cards cover what is already in your repositories and registry. To scan an image the moment it is built, Safeguard's container image CI docs show a single CLI step. The Safeguard CLI (GA) scans the image on the runner and records it in Safeguard under the image's repository, one version per environment and tag:

safeguard ci scan --image "ghcr.io/acme/api:$TAG" --environment prod --wait --fail-on critical

The example in the docs uses a GitHub registry path; for OCIR the image reference would be your OCIR path. The docs give the setup: get a secret key with scans:trigger and scans:read, store it as SAFEGUARD_API_KEY in your CI, and add the step after the image is built in each environment's pipeline. When the step does not run on the machine that built the image, set SAFEGUARD_REGISTRY_USERNAME and SAFEGUARD_REGISTRY_PASSWORD as CI secrets so the scan can pull it; for OCIR those would be the namespace-form username and an auth token with read repos. Only the results leave the runner.

Safeguard's CI docs list examples for several CI systems. OCI DevOps build pipelines are not among the named examples, so check with your Safeguard contact before you plan the build-stage step around them. The connection-based scans in parts one and two do not depend on it.

Part four: put a gate on it

Policies and gates (GA) decide what a finding means for a release. Per Safeguard's docs, policies evaluate your SBOMs and generate findings, and gates are the checkpoints that enforce them. Conditions include vulnerability severity, CVSS score, EPSS score, license and component age, and there are templates such as No Critical Vulnerabilities and License Compliance.

Each policy has one Action:

Approval for a known, accepted risk runs through exceptions rather than switching the gate off. Per the docs, you click Request Exception, select the policy and finding, give a business justification and an expiration date, and submit it for approval; approvers are notified and grant or deny it. In CI, the docs show:

safeguard ci scan --wait --fail-on-gate <gate name or id | all>

which exits 0 when the gate is Passed or Warning, and non-zero when it is Failed, Error or Not evaluated. Safeguard's docs note that gate outcomes are turned on per workspace, so ask your Safeguard contact if the Outcome column is missing.

Part five: fix where the code lives

Because the OCI DevOps card can open pull requests, the loop closes in the repository. With an API signing key on the connection and the manage devops-repository policy, autonomous remediation with Griffin fix pull requests (GA) can create a branch, push a dependency fix and open the pull request in OCI DevOps. On an auth-token-only connection, Safeguard tells you that fix pull requests need the API signing key as well. Autonomous remediation ships switched off, with every category set to Manual, so nothing is opened on its own until your team decides it should be.

The image side follows: once the fix merges, your build pipeline produces a new image, and the next OCIR scan (scheduled or by hand) records the new digest with its new findings.

A day-one rollout plan

Troubleshooting the errors you will actually see

The Safeguard docs list the messages for each card. The ones that come up most:

Rotation and disconnect

Both cards rotate the same way. Generate a second auth token (or add a second API key) for the integration user. Under Project Configurations on the Project/Product tab, open the connection's menu, choose Update, enter the new credentials, click Verify Credentials and save. Then delete the old token or key in the OCI Console. The docs suggest a fixed schedule such as every 90 days; Oracle's tokens and keys do not expire on their own, so the schedule is yours to keep.

To disconnect, choose Delete from the connection's menu under Project Configurations and confirm Delete configuration. Then delete the auth token and API key (or the whole integration user) in OCI, and for the DevOps card also delete the Notifications subscription and Events rule if you created them.

What Safeguard does not do

• It does not support government or sovereign OCI clouds yet. Both cards accept commercial regions only. If your workloads run in a government cloud, these cards cannot reach them today.
• It does not accept instance principals, resource principals, workload identity or OCI session tokens. Both cards take user credentials only. That means you own a long-lived secret and its rotation schedule.
• The OCIR card has no push trigger. New tags are picked up by a schedule or a manual rescan, not the moment they land in the registry. If you need build-time evidence, add the CLI step to your pipeline.
• An auth-token-only DevOps connection cannot list repositories or open fix pull requests. You add each repository by URL, and remediation needs the API signing key and the manage devops-repository policy.
• It does not patch images in place. Fix pull requests go to the code repository. A fixed image only exists once your pipeline rebuilds and pushes it.
• It does not decide your exceptions. Gates apply Block, Warn and Notify as configured. Who may accept a risk, for how long, and on what evidence is your call.
• It does not manage your OCI IAM. The docs give the statements; your administrators create the user, group and policies, and own their review.
• It does not replace OCI's own controls. Safeguard reads your repositories and images. Network policy, Cloud Guard findings, OKE hardening and Vault secrets remain your own configuration.

Common mistakes

1. Using the namespace as the DevOps username, or the tenancy name as the OCIR username. The two services build the username from different identifiers. When they happen to match in older tenancies, the mistake hides until you add a new tenancy.
2. Granting inspect repos and wondering why scans fail. Inspect lists; it does not pull. Oracle's examples and Safeguard's docs both say read repos.
3. Granting manage to "make it work". If a clone is refused, the fix is use devops-repository, not manage devops-family.
4. Scanning by tag and filing the result as evidence. Record the digest, and compare it with what is deployed.
5. Connecting with a person's own credentials. Safeguard's docs say this works but is not recommended, because the credential carries every permission that person's groups have, and it dies when they leave.
6. Skipping the schedule because push triggers are on. Push triggers rescan when code changes. Advisories arrive when code does not change. You need both.
7. Leaving the push subscription secret in a ticket or chat. Anyone with it can start rescans on the connection.
8. Turning on every remediation category on day one. Start with Manual, review the first batch of fix pull requests, then decide.
9. Forgetting to delete the Events rule and subscription when you disconnect. They keep sending messages to an endpoint that no longer expects them.

FAQ

How do I scan Oracle Cloud DevOps repositories for vulnerabilities?

Clone each repository at the branch or tag you ship and run a software composition scan that produces an SBOM and findings. With Safeguard, connect the Oracle Cloud DevOps card under Integrations with a dedicated user's API signing key and auth token, select the repositories and branches, and each one becomes a project that is scanned on connect, on a schedule and, optionally, on push.

What IAM policy does a scanner need for OCI DevOps code repositories?

read devops-family in the compartment that holds the DevOps projects. Add use devops-repository only if Oracle refuses the clone. Add manage devops-repository only if you want the scanner to open fix pull requests.

What IAM policy does a scanner need for OCIR?

read repos, in the tenancy or, better, in the compartment that holds the images. inspect repos is not enough, because it cannot pull.

What username do I use for an OCI auth token?

For DevOps Git over HTTPS, the tenancy name followed by the user (with the identity domain, or oracleidentitycloudservice for federated users, in the middle). For OCIR, the Object Storage namespace followed by the user. The password is the auth token in both cases.

Can Safeguard scan OCI DevOps repositories on every push?

Yes, through OCI Events and Notifications. The connection shows a Subscription URL; you create a Notifications topic with an HTTPS (Custom URL) subscription to it, then an Events rule for the DevOps receive-pack event types with the topic as its action.

Does Safeguard store my source code or image layers?

No. Per Safeguard's docs, the DevOps scanner clones into a temporary folder and deletes it when the scan ends, and OCIR images are read for the scan and not kept. Safeguard stores the SBOM and findings, the connection settings and the encrypted credentials.

Can Safeguard push, delete or retag images in OCIR?

No. Per the docs, the OCIR card only reads and never needs manage repos or use repos.

Does Safeguard work with OCI government regions?

Not yet. Both cards support commercial regions only.

How do I stop a vulnerable image from being deployed?

Link a policy to a gate with the Block action, and in your pipeline run safeguard ci scan with --fail-on-gate so the job fails when the gate fails. Use Warn or Notify for issues that should not stop a release, and handle accepted risks through exceptions.

Two connections, one user, two policies: that is the whole access footprint for OCI. What follows is the part that matters after the scans come back, when a fixed version exists or does not exist yet for the packages they flag.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session: install, open the interactive terminal, and ask it to fix a lodash CVE in a repository. It reads the finding and advisory, asks before any command that changes something, edits package.json, runs the install and tests with approval, and pushes nothing. It is the same CLI the pipeline step above calls, and the same kind of dependency fix you would make in a cloned OCI DevOps repository.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. It is useful when you want to try scans from a workstation before wiring the CLI step into a pipeline.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. Once your OCI repositories and images are projects in Safeguard, that connection is how an assistant reaches their findings.

Click through it at your own pace, or open it full screen.

Quick check

Related reading

• Scanning Oracle Cloud Infrastructure Registry images for vulnerabilities
• Designing least privilege IAM policies in Oracle Cloud Infrastructure
• OCI registry tag or digest: what pull and delete guarantee
• Hardening Oracle Kubernetes Engine (OKE) clusters
• Managing secrets securely with OCI Vault

Sources

• Safeguard docs: Oracle Cloud DevOps integration
• Safeguard docs: Oracle Container Registry (OCIR) integration
• Safeguard docs: OCI Registry integration
• Safeguard docs: Container images in CI/CD
• Safeguard docs: Policies and Gates
• Safeguard docs: Policy outcomes and actions
• Oracle: DevOps overview
• Oracle: DevOps IAM policies
• Oracle: HTTPS authorization for DevOps code repositories
• Oracle: Managing pull requests
• Oracle: DevOps events
• Oracle: Overview of Container Registry
• Oracle: Policies to control repository access
• Oracle: Pulling images using the Docker CLI
• Oracle: Getting an auth token
• Oracle: Required keys and OCIDs
• NIST SP 800-218, Secure Software Development Framework version 1.1
• NIST SP 800-190, Application Container Security Guide
• Open Container Initiative Distribution Specification

Download Safeguard at safeguard.sh/download, and read the product documentation at docs.safeguard.sh.

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.