DEV Community: Siri Varma Vegiraju

Docker Scout Commands

Siri Varma Vegiraju — Wed, 20 Aug 2025 05:03:01 +0000

Docker Scout Overview

Docker Scout is a solution for proactively enhancing your software supply chain security. By analyzing your images, Docker Scout compiles an inventory of components, also known as a Software Bill of Materials (SBOM). The SBOM is matched against a continuously updated vulnerability database to identify security vulnerabilities and provide actionable insights for improving your container security posture.

Docker Scout Commands

Docker Scout provides 18 subcommands for various security analysis and management tasks:

Core Analysis Commands:

docker scout quickview - Displays a quick overview of an image. It displays a summary of the vulnerabilities in the specified image and vulnerabilities from the base image. If available, it also displays base image refresh and update recommendations.
docker scout cves - Analyzes a software artifact for vulnerabilities. If no image is specified, the most recently built image is used.
docker scout compare - Compares two images and displays the differences in vulnerabilities and components
docker scout sbom - Generates or analyzes Software Bill of Materials for images

Management and Configuration:

docker scout config - Configure Docker Scout settings and organization
docker scout enroll - Enroll repositories for Docker Scout analysis
docker scout push - Push analysis results to Docker Scout
docker scout cache - Manage local analysis cache

Advanced Features:

docker scout policy - Manage and evaluate security policies
docker scout recommendations - Get actionable recommendations for improving security
docker scout attestation - Work with supply chain attestations
docker scout environment - Manage environments for policy evaluation
docker scout integration - Manage third-party integrations
docker scout repo - Repository management commands
docker scout stream - Stream analysis data
docker scout watch - Monitor repositories for changes
docker scout version - Display version information

The CLI provides both local analysis capabilities and integration with Docker's cloud-based Scout service for comprehensive vulnerability management across your container ecosystem.

Docker 4.44 is here

Siri Varma Vegiraju — Tue, 19 Aug 2025 04:35:01 +0000

AI/ML Enhancements

Docker Model Runner improvements include an inspector for AI inference requests and responses, allowing developers to debug model behavior by examining HTTP payloads, prompts, and outputs. The update also adds real-time resource checks to prevent system freezes when running multiple models concurrently, with warnings for GPU and memory constraints.

Expanded MCP (Model Context Protocol) support now includes Goose and Gemini CLI as clients, providing one-click access to over 140 MCP servers like GitHub, Postgres, and Neo4j through the Docker MCP Catalog.

Developer Experience

New Kubernetes CLI command (docker desktop kubernetes) allows managing Kubernetes clusters directly from the Docker Desktop CLI without switching between tools or UI screens.

Improved Settings search helps users find configurations faster without navigating through multiple menus.

Platform Performance

Apple Virtualization is now the default backend on macOS (QEMU support fully removed), delivering better performance with faster cold starts and more efficient memory management.

WSL2 improvements on Windows include reduced memory consumption, smarter CPU throttling for idle containers, and better stability for graphics-heavy workloads.

The release focuses on enhanced reliability, better AI development tools, and streamlined workflows to help developers build and test applications more efficiently, particularly those working with AI/ML models.

Docker AI and MCP commands

Siri Varma Vegiraju — Mon, 11 Aug 2025 04:43:26 +0000

Core Docker AI Commands

`docker ai`

The primary command to interact with Gordon (Docker's AI agent) from the terminal. Gordon looks for a gordon-mcp.yml file in your working directory to determine which MCP servers to use.

Usage:

docker ai "your question or request"

MCP Configuration File

`gordon-mcp.yml`

A Docker Compose configuration file that defines MCP servers for Gordon to use. This file should be placed in your working directory.

Example structure:

services:
  mcp-time:
    image: mcp/time
    # Additional MCP server configurations

Docker MCP Toolkit Features

MCP Toolkit Extension

An extension available in Docker Desktop Dashboard that lets you run MCP-enabled tools as containers behind an MCP Server proxy.

Key capabilities:

Browse and install MCP servers from the Docker MCP Catalog
Configure MCP servers with necessary credentials
Enable/disable MCP tools for your AI workflows

Available MCP Servers

Based on the search results, here are some notable MCP servers available:

Docker Hub MCP Server - Allows interaction with Docker Hub, requires Docker Hub username and personal access token for configuration
PostgreSQL MCP Server (mcp/postgres) - Enables AI assistants to interact directly with PostgreSQL databases, allowing database-aware conversations, queries, and schema modifications
Time MCP Server (mcp/time) - Provides time-related functionality, as shown in the example where Gordon can answer time queries for different locations

How MCP Works with Docker AI

MCP functions as a client-server protocol where the client (like Gordon) sends requests, and the server processes those requests to deliver necessary context to the AI. When Gordon uses MCP, you'll see output indicating it's calling the MCP server's tools, such as "Calling get_current_time ✔️".

Installation and Setup

Ensure Docker Desktop is installed and updated
Add the MCP Toolkit Extension to the Docker Desktop Dashboard
Browse available MCP servers in the Catalog tab
Configure servers with necessary credentials
Create a gordon-mcp.yml file in your project directory
Use docker ai commands to interact with Gordon

Dapr support with Postgres

Siri Varma Vegiraju — Fri, 08 Aug 2025 05:47:11 +0000

Overview

Dapr supports using PostgreSQL as a configuration store component of type configuration.postgresql, with a stable API (v1) since Dapr runtime version 1.11 ([Dapr Docs][1]).

Component Setup

Component Definition

You create a Dapr component manifest like so:

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: <YOUR_NAME>
spec:
  type: configuration.postgresql
  version: v1
  metadata:
    - name: connectionString
      value: "<your connection string>"
    - name: table
      value: "<your_configuration_table_name>"
    # Optional metadata fields include:
    - name: timeout
      value: "30s"
    - name: maxConns
      value: "4"
    - name: connectionMaxIdleTime
      value: "5m"
    - name: queryExecMode
      value: "simple_protocol"

Key metadata options:

connectionString (required): Standard PostgreSQL connection string, allowing pool configuration parameters ([Dapr Docs][2]).
table (required): Name of the table to store configuration entries ([Dapr Docs][2]).
Optional tuning metadata:
- timeout (database operation timeout)
- maxConns (connection pool size)
- connectionMaxIdleTime
- queryExecMode: useful for compatibility with certain proxies like PgBouncer ([Dapr Docs][2]).

Database Schema & Triggers

Table Schema

You must create a table with the following structure:

CREATE TABLE IF NOT EXISTS <table_name> (
  KEY VARCHAR NOT NULL,
  VALUE VARCHAR NOT NULL,
  VERSION VARCHAR NOT NULL,
  METADATA JSON
);

KEY: configuration attribute key
VALUE: associated value
VERSION: version identifier
METADATA: optional JSON metadata ([Dapr Docs][2])

Notification Trigger

To enable subscription notifications, define a trigger function and create a trigger:

CREATE OR REPLACE FUNCTION notify_event() RETURNS TRIGGER AS $$
DECLARE 
    data json;
    notification json;
BEGIN
    IF (TG_OP = 'DELETE') THEN
        data = row_to_json(OLD);
    ELSE
        data = row_to_json(NEW);
    END IF;
    notification = json_build_object(
                      'table', TG_TABLE_NAME,
                      'action', TG_OP,
                      'data', data);
    PERFORM pg_notify('config', notification::text);
    RETURN NULL;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER config
AFTER INSERT OR UPDATE OR DELETE ON <configtable>
FOR EACH ROW EXECUTE PROCEDURE notify_event();

You will then use the same channel name (e.g., "config") in pg_notify when subscribing ([Dapr Docs][2]).

Dapr Configuration API Integration

Dapr provides REST APIs to interact with the configuration store:

Get Configuration
GET http://localhost:<daprPort>/v1.0/configuration/<storeName>?key=...
- Returns key-value pairs as JSON ([Dapr Docs][3]).
Subscribe to Changes
GET http://localhost:<daprPort>/v1.0/configuration/<storeName>/subscribe?...&metadata.pgNotifyChannel=<channel>
- metadata.pgNotifyChannel must match the channel used in your PostgreSQL trigger ("config" in the example) ([Dapr Docs][3]).
Unsubscribe
GET http://localhost:<daprPort>/v1.0/configuration/<storeName>/<subscription-id>/unsubscribe
- Use the subscription ID returned earlier to cancel listening ([Dapr Docs][3]).

Policy as code with Open Policy Agent

Siri Varma Vegiraju — Wed, 06 Aug 2025 05:22:53 +0000

Policy as Code

Policy as Code is the practice of writing and managing security, compliance, and operational rules in code—just like you manage application code. It allows policies to be:

Automated: Integrated into CI/CD pipelines and runtime systems
Versioned: Stored in source control systems (e.g., Git)
Tested: With unit/integration tests, reducing human error
Audited: For traceability and accountability

This approach promotes consistency, repeatability, and scalability in enforcing rules across infrastructure, Kubernetes, APIs, IAM, and more.

Open Policy Agent (OPA)

OPA is a general-purpose policy engine that lets you enforce fine-grained policies across a wide range of systems.

Uses a high-level declarative language called Rego
Decouples policy decisions from policy enforcement
Can be embedded in services (e.g., microservices, Kubernetes admission controllers, CI/CD pipelines)

Common Use Cases:

Kubernetes Admission Control (via Gatekeeper)
API access authorization
Cloud infrastructure policies (Terraform, CI/CD)
Data filtering and masking

Example (OPA Rego Policy):

package httpapi.authz

allow {
  input.user == "admin"
  input.method == "DELETE"
}

This policy allows only admin users to perform DELETE operations.

Why it Matters

OPA and Policy as Code are central to Cloud Native Security, Zero Trust Architecture, and automated compliance in modern DevSecOps environments.

How Docker MCP helps discover containerized MCP serviers

Siri Varma Vegiraju — Fri, 01 Aug 2025 04:27:37 +0000

Docker has launched the Docker MCP Catalog and Toolkit in beta to address key challenges in the Model Context Protocol (MCP) ecosystem for AI agents. Here's what's new:

Docker MCP Catalog

The Docker MCP Catalog is now integrated into Docker Hub and serves as a centralized discovery platform for MCP servers. It features over 100 curated, containerized MCP servers from trusted partners including Stripe, Elastic, Heroku, Pulumi, Grafana Labs, Kong Inc., Neo4j, New Relic, and Continue.dev. The catalog makes it easy to find official, trustworthy MCP tools in one place rather than searching across fragmented registries and community lists.

Container MCP Approach

By packaging MCP servers as Docker containers, the solution eliminates common deployment challenges like runtime setup, dependency conflicts, and environment inconsistencies. Containers provide built-in security features, isolation, and sandboxing that traditional MCP installations lack. This containerized approach also enables better protection against emerging threats specific to MCP servers, such as Tool Poisoning and Tool Rug Pull attacks.

MCP Toolkit Features

The MCP Toolkit, available as a Docker Desktop extension, provides:

Simple Installation: One-click setup and management of MCP servers
Secure Authentication: Built-in OAuth support and secure credential storage, eliminating the need for plaintext environment variables
Client Integration: Seamless connection to popular MCP clients like Gordon (Docker AI Agent), Claude, Cursor, VSCode, Windsurf, Continue.dev, and Goose
Enterprise Features: Access control, policy enforcement, and audit capabilities

Key Benefits

The containerized MCP approach solves three major pain points in the current MCP ecosystem: fragmented discovery of trustworthy tools, complex installations with dependency conflicts, and inadequate security with full host access. Docker's solution provides a secure, scalable foundation that inherits Docker's trusted container security model while simplifying the developer experience for building AI agents with external tool integrations.

The beta is available now through Docker Desktop's extensions menu, with plans to expand enterprise features and enable custom MCP sharing through Docker Hub.

Docker Offload is Simply Amazing

Siri Varma Vegiraju — Tue, 29 Jul 2025 05:30:11 +0000

🚀 What Is Docker Offload?

Docker Offload is a beta feature of Docker Desktop (version 4.43+), allowing you to offload Docker image builds and container execution to remote cloud infrastructure while maintaining your familiar local development workflow.

🔑 Core Features

Remote builds & runs: Your docker build and docker run commands execute on cloud-based BuildKit instances or managed container environments. Builds and GPU workloads run remotely, not on your local machine.
GPU support: Optionally run on NVIDIA L4 GPU instances—ideal for machine learning, AI inferencing, or media processing .
Ephemeral environments: A fresh cloud session is provisioned for each user session and automatically torn down after ~5 minutes of inactivity, cleaning up containers, images, and volumes.
Shared build cache: Persistent cache across builds and team members speeds up build performance and avoids redundant downloads.
Local-like UX: Port forwarding, bind mounts, and accessing containers via localhost work just like local Docker. No change to Dockerfiles or commands is required.
Secure communication: Docker Desktop connects to cloud builders over encrypted tunnels, using credentials and secure access flows.

⚙ How to Get Started (Quickstart)

Install Docker Desktop 4.43 or later and sign up for the Offload beta.
Run:

   docker offload start

Follow prompts to select your account and enable optional GPU support.

Check status with:

   docker offload status

And verify context using:

   docker context ls

You’ll see a cloud-based context—often named docker-cloud—active once offloading is enabled.

Run containers normally, for example:

   docker run --rm hello-world
   docker run --rm --gpus all hello-world

The containers execute in the cloud but behave just like local ones (even ports map to localhost).

When finished, stop the session via:

   docker offload stop

Builds and runs revert to local execution.

📊 Why Use Docker Offload?

Speed and scale: Ideal for resource-intensive builds and workloads that would overwhelm a local machine (e.g. monorepos, large Node dependencies).
Consistency: Ensures identical builds across developers and CI environments without managing custom infrastructure or Docker-in-Docker setups.
Cost flexibility: You get 300 minutes of free usage to start.
Hardware offloading: Keep your laptop cool and responsive while heavy workloads run remotely.

✅ Summary

Docker Offload is a powerful way to run container workloads and builds in the cloud—with GPU support, managed infrastructure, and consistent UI—while preserving your local development habits. It’s ideal for heavy-duty workflows, complex builds, or low-power environments, offering major performance gains with minimal setup changes.

Setting up Azure Container Apps and Dapr

Siri Varma Vegiraju — Mon, 28 Jul 2025 04:38:49 +0000

Getting Started with Azure Container Apps and Dapr

Azure Container Apps is a serverless container platform that enables you to deploy microservices without managing complex infrastructure. When combined with Dapr (Distributed Application Runtime), it unlocks powerful capabilities like service invocation, pub/sub messaging, state management, and more—ideal for building resilient, cloud-native apps.

Prerequisites

Azure CLI
Dapr CLI
A GitHub repo or container image (e.g., from Docker Hub)
Azure Subscription

Step 1: Enable Azure CLI Extensions

Install the required extensions:

az extension add --name containerapp --upgrade
az provider register --namespace Microsoft.App
az provider register --namespace Microsoft.OperationalInsights

Step 2: Create a Resource Group and Environment

az group create --name dapr-app-rg --location westus

az containerapp env create \
  --name dapr-env \
  --resource-group dapr-app-rg \
  --location westus

Step 3: Deploy a Container App with Dapr Enabled

Deploy a sample app with Dapr sidecar:

az containerapp create \
  --name dapr-service \
  --resource-group dapr-app-rg \
  --environment dapr-env \
  --image ghcr.io/dapr/samples/hello-k8s-node:latest \
  --target-port 3000 \
  --ingress external \
  --enable-dapr \
  --dapr-app-id nodeapp \
  --dapr-app-port 3000

--enable-dapr deploys the Dapr sidecar
--dapr-app-id is used for service invocation

Step 4: Test Dapr Service Invocation

To invoke the service from another app or tool:

curl http://<container-app-url>/ \
  -H "dapr-app-id: nodeapp"

Step 5: Add Pub/Sub or State Store (Optional)

Attach a pub/sub component or state store by uploading a Dapr component YAML file to your Container App environment via the Azure Portal or Azure CLI. For example, use Azure Storage, Service Bus, or Redis as backends.

Summary

By enabling Dapr in Azure Container Apps, you can focus on building scalable microservices without worrying about infrastructure. You get out-of-the-box service discovery, retries, pub/sub, and state—making your app more robust and cloud-native.

Dapr and Grafana for Metrics

Siri Varma Vegiraju — Fri, 25 Jul 2025 06:27:57 +0000

Prerequisites

Prometheus must be set up and scraping Dapr metrics before using Grafana (Dapr Docs).

Setup on Kubernetes

1. Install Grafana

Add the Helm repo:

  helm repo add grafana https://grafana.github.io/helm-charts
  helm repo update

Install Grafana in the dapr-monitoring namespace:

  helm install grafana grafana/grafana -n dapr-monitoring

Optional: For development or Minikube, disable persistent volumes:

  --set persistence.enabled=false

Retrieve the Grafana admin password via Kubernetes secret and base64 decoding: remove trailing % from output string (Dapr Docs)
Confirm Grafana and Prometheus pods are running via kubectl get pods -n dapr-monitoring (Dapr Docs).

2. Configure Prometheus Data Source in Grafana

Port-forward the Grafana service to localhost:8080, then navigate to http://localhost:8080:

  kubectl port-forward svc/grafana 8080:80 -n dapr-monitoring

Log in with user admin and the decoded password
Under Configuration → Data Sources, add Prometheus
Set the HTTP URL to the Prometheus server endpoint, e.g.: http://dapr-prom-prometheus-server.dapr-monitoring based on service name and namespace (Dapr Docs)
Enable as default and disable TLS verification (Skip TLS Verify On) for connection saving to succeed
Save & Test to ensure the data source is correctly connected (Dapr Docs)

3. Import Dashboards

From Grafana home screen, click "+ → Import"
Upload the .json dashboard file(s) corresponding to your Dapr version
Available dashboard templates include:
- System Service: shows control-plane components like operator, injector, sentry, placement
- Sidecars: shows health, resource use, throughput/latency (HTTP, gRPC), mTLS, Actor metrics
- Actors: shows actor invocation metrics, timers, reminders, concurrency usage (Dapr Docs)
After importing, locate and open the dashboard(s) to begin visualizing metrics

Observability Insights

Dapr sidecars and control-plane services expose Prometheus-formatted metrics, which Prometheus scrapes on default ports (9090 for sidecar, 9091 for control-plane) (DEV Community, Dapr Docs)
Sidecar metrics include latency for service invocation, state/store calls, pub-sub, memory usage, error rates
Control-plane metrics include CPU usage, actor placements, injection failures, etc. (DEV Community, Dapr Docs)

Summary & Tips

Install Prometheus and Grafana (via Helm)
Connect Grafana to Prometheus as a data source
Import pre-built dashboards for system services, sidecars, and actor workloads
Use Grafana to visualize key metrics: latency, throughput, resource usage, failures, actor behavior
Hover over the "i" icons inside Grafana charts for descriptions of what each metric means (Dapr Docs)

Intro to OpenTelemetry Weaver

Siri Varma Vegiraju — Tue, 22 Jul 2025 06:15:50 +0000

📌 TL;DR

OpenTelemetry Weaver is a powerful tool that brings observability-by-design into practice. It empowers teams to standardize, automate, and maintain telemetry data through semantic conventions—offering type safety, validation, documentation, and deployment in one package ([OpenTelemetry][1]).

Why Weaver Matters

Weaver addresses common issues in telemetry reliability and consistency:

Broken alerts due to metric name changes
Hard-to-read queries from inconsistent naming
Undocumented telemetry leading to confusion
Missing instrumentation, only discovered in production ([GitHub][2])

By treating telemetry signals (traces, metrics, logs) like code APIs, Weaver ensures they are versioned, consistent, and documented upfront.

Core Features

OTel Weaver supports:

Capability	Description
Schema Definition	Define telemetry schemas via semantic conventions.
Validation	Validate telemetry against defined schemas manually or in CI.
Type-safe Code Gen	Generate idiomatic client SDKs (Go, Rust, etc.) from those schemas.
Documentation Gen	Auto-generate markdown docs for your signals.
Live Checking	Integrate in CI or runtime to ensure emitted telemetry conforms ([Honeycomb][3], [GitHub][2], [GitHub][4]).

How It Works

At its core, Weaver is a CLI and platform tool that uses a schema-first workflow:

Search or resolve semantic convention registries and schemas.
Validate schemas via the CLI.
Generate client SDKs, docs, or dashboards using its built‑in template engine or custom WASM plugins ([GitHub][4]).

Current Maturity & Roadmap

Versioned as CLI v0.X, Weaver is production-ready with active releases (v0.16.1 as of July 4, 2025) ([GitHub][2])
Future roadmap includes expanding language support, integrating OTel Arrow Protocol, adding SDK masking, obfuscation, and a richer ecosystem with WASM plugins for data catalogs, privacy compliance, dashboards, and more ([GitHub][4]).

Learn More

Get Better OpenTelemetry with Weaver

Check out the CNCF 2025 presentation “Observability by Design” and the SRECon talk “OpenTelemetry Semantic Conventions and How to Avoid Broken Observability”, both linked in the repo ([GitHub][2]).

💡 Quick Take

OTel Weaver elevates telemetry from artistry to engineering discipline. It helps teams define telemetry as a "public API," bringing consistency, traceability, and automation. Ideal for organizations prioritizing high-quality, maintainable observability at scale.

Source: https://opentelemetry.io/blog/2025/otel-weaver/

How Dapr Binding works ?

Siri Varma Vegiraju — Mon, 21 Jul 2025 06:04:11 +0000

🔗 Dapr Bindings Overview Summary

Bindings in Dapr provide a way for applications to interact with external systems—both to ingest events (input bindings) and to invoke external systems (output bindings)—using a simple, consistent API.

🧩 Types of Bindings

Input Bindings

Trigger the application by receiving events from external systems (e.g., message queues, databases, cloud services).
Dapr invokes a specified endpoint in the app when a new event arrives.

Output Bindings

Allow the app to send data to external systems.
Can be invoked using Dapr SDKs or HTTP/gRPC APIs.

🔄 How Bindings Work

Input: External system → Dapr → App
Output: App → Dapr → External system
Bindings are configured via a component YAML file defining the type (e.g., Kafka, HTTP, Cron) and metadata.

🧰 Use Cases

Trigger functions on a schedule (e.g., cron)
Send messages to systems like Kafka, MQTT
Respond to cloud events from AWS, Azure, GCP
Connect with databases, queues, or custom services

✅ Benefits

Abstracts complex integrations
Uniform API across different services
Event-driven programming with minimal boilerplate

Generating CylconeDX and SPDX format SBOMs using Docker Scout

Siri Varma Vegiraju — Fri, 18 Jul 2025 05:56:21 +0000

Software Bill of Materials (SBOM) Guide with Docker Scout

What is an SBOM?

A Software Bill of Materials (SBOM) is a comprehensive inventory of all software components, libraries, dependencies, and packages that make up a software application or system. Think of it as an "ingredients list" for your software - just like food labels list ingredients, an SBOM lists all the software components used in your application.

Why are SBOMs Important?

SBOMs have become critical for modern software development and security for several reasons:

Security & Vulnerability Management: Quickly identify if your software contains vulnerable components
Compliance & Regulatory Requirements: Many industries and government contracts now require SBOMs
Supply Chain Transparency: Understand what third-party code you're using and its origins
License Compliance: Track open-source licenses and ensure compliance with terms
Risk Assessment: Evaluate the security posture of your software stack
Incident Response: Rapidly determine if security incidents affect your applications

Key SBOM Formats

1. SPDX (Software Package Data Exchange)

Industry Standard: Developed by the Linux Foundation
Format: Available in JSON, YAML, RDF, and tag-value formats
Use Case: Widely adopted, especially in open-source communities
Strengths: Comprehensive license information, mature specification

2. CycloneDX

Modern Format: Designed specifically for application security use cases
Format: Available in JSON and XML formats
Use Case: Popular in DevSecOps and vulnerability management
Strengths: Rich vulnerability data, component relationships, build metadata

3. SWID (Software Identification Tags)

Legacy Format: Older standard, less commonly used for modern applications
Use Case: Primarily for software asset management

Using Docker Scout to Generate SBOMs

Docker Scout is Docker's built-in security and supply chain tool that can generate SBOMs for container images. Here's how to use it:

Basic SBOM Generation

# Generate SPDX SBOM (JSON format)
docker scout sbom --format spdx my-app:latest

# Generate CycloneDX SBOM (JSON format)
docker scout sbom --format cyclonedx my-app:latest

Save SBOMs to Files

# Save SPDX SBOM to file
docker scout sbom --format spdx --output my-app-sbom.spdx.json my-app:latest

# Save CycloneDX SBOM to file
docker scout sbom --format cyclonedx --output my-app-sbom.cyclonedx.json my-app:latest

# Generate XML format for CycloneDX
docker scout sbom --format cyclonedx --output my-app-sbom.cyclonedx.xml my-app:latest

Advanced Options

# Generate SBOM for specific platform
docker scout sbom --format spdx --platform linux/amd64 my-app:latest

# Generate SBOM for remote image
docker scout sbom --format cyclonedx nginx:alpine

# Generate SBOM with organization context
docker scout sbom --format spdx --org my-org my-app:latest

Practical Workflow Example

Here's a typical workflow for integrating SBOM generation into your CI/CD pipeline:

# 1. Build your Docker image
docker build -t my-app:v1.0.0 .

# 2. Generate SBOMs in both formats
docker scout sbom --format spdx --output artifacts/sbom.spdx.json my-app:v1.0.0
docker scout sbom --format cyclonedx --output artifacts/sbom.cyclonedx.json my-app:v1.0.0

# 3. Store SBOMs with your artifacts for compliance and security tracking

What Information is Included?

Docker Scout-generated SBOMs typically include:

Package Information: Name, version, type (npm, pip, apt, etc.)
Dependencies: Direct and transitive dependencies
File Locations: Where components are installed in the container
Licenses: License information for each component
Checksums: File integrity information
Metadata: Build information, timestamps, and more

Integration with Security Tools

SBOMs generated by Docker Scout can be consumed by various security and compliance tools:

Vulnerability Scanners: Import SBOMs to identify known vulnerabilities
Compliance Tools: Verify license compliance and policy adherence
Supply Chain Security: Track component provenance and integrity
Risk Management: Assess overall security posture of applications