{"id":792,"date":"2026-04-16T04:23:07","date_gmt":"2026-04-16T04:23:07","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-assured-open-source-software-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-security\/"},"modified":"2026-04-16T04:23:07","modified_gmt":"2026-04-16T04:23:07","slug":"google-cloud-assured-open-source-software-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-security","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-assured-open-source-software-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-security\/","title":{"rendered":"Google Cloud Assured Open Source Software Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Security"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Security<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>Assured Open Source Software is a Google Cloud Security service that helps you consume open source packages with stronger supply-chain assurances than \u201cdownload from the internet and hope for the best.\u201d It focuses on providing vetted, monitored, and verifiable open source artifacts that can be used in your build and deployment pipelines.<\/p>\n\n\n\n<p>In simple terms: <strong>Assured Open Source Software gives you a trusted source of common open source dependencies<\/strong> (such as container base images and\/or language packages, depending on what Google currently offers), so your teams can reduce exposure to malicious or compromised upstreams, typosquatting, and unpatched vulnerabilities.<\/p>\n\n\n\n<p>Technically, Assured Open Source Software is best understood as a <strong>curated, Google-managed distribution channel for selected open source artifacts<\/strong> paired with supply-chain security metadata and practices (for example, vulnerability monitoring and provenance-related signals). It is designed to integrate with Google Cloud\u2019s artifact and deployment ecosystem (most commonly <strong>Artifact Registry<\/strong>, and then build\/deploy services like <strong>Cloud Build<\/strong>, <strong>Cloud Run<\/strong>, and <strong>GKE<\/strong>).<\/p>\n\n\n\n<p>The problem it solves is the modern software supply-chain risk: most applications are mostly dependencies, and dependency compromise (malicious packages, poisoned upstreams, dependency confusion, and slow vulnerability patch adoption) is now a primary Security concern. Assured Open Source Software helps you <strong>standardize where dependencies come from<\/strong> and <strong>raise the assurance level<\/strong> of what enters your SDLC.<\/p>\n\n\n\n<blockquote>\n<p>Naming note (important): Google\u2019s current documentation and console UI may shorten the name to <strong>\u201cAssured OSS\u201d<\/strong>. This tutorial uses <strong>Assured Open Source Software<\/strong> as the primary name, and treats \u201cAssured OSS\u201d as a common shorthand. Verify the latest naming and scope in the official docs.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Assured Open Source Software?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Official purpose<\/h3>\n\n\n\n<p>Assured Open Source Software is intended to provide <strong>more secure consumption of open source software<\/strong> by offering a <strong>trusted channel<\/strong> for selected open source packages\/artifacts, backed by Google\u2019s security and supply-chain practices.<\/p>\n\n\n\n<p>Because the exact artifact types and coverage can evolve, you should confirm the currently supported ecosystems (containers, language packages, OS packages, etc.) in the official documentation:\n&#8211; https:\/\/cloud.google.com\/assured-open-source-software (product page)\n&#8211; https:\/\/cloud.google.com\/assured-open-source-software\/docs (documentation hub)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities (conceptual)<\/h3>\n\n\n\n<p>Commonly documented capabilities and outcomes include:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Curated availability<\/strong> of popular open source artifacts (not \u201ceverything on the internet\u201d).<\/li>\n<li><strong>Security monitoring<\/strong> for vulnerabilities and updates in the supported artifact set.<\/li>\n<li><strong>Supply-chain signals<\/strong> (for example provenance-related information), depending on artifact type and what Google publishes for that artifact.<\/li>\n<li><strong>Integration with Google Cloud artifact and deployment tooling<\/strong>, so developers can adopt it without reinventing tooling.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components (typical in Google Cloud usage)<\/h3>\n\n\n\n<p>Assured Open Source Software is usually consumed together with:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Assured Open Source Software catalog\/repositories<\/strong> (Google-managed)<\/li>\n<li><strong>Artifact Registry<\/strong> for artifact consumption and governance (repositories, IAM, audit logs)<\/li>\n<li>Optional but common:<\/li>\n<li><strong>Cloud Build<\/strong> (build pipelines)<\/li>\n<li><strong>Cloud Run<\/strong> \/ <strong>GKE<\/strong> (runtime)<\/li>\n<li><strong>Binary Authorization<\/strong> (admission control for container images in GKE; applicability depends on your architecture)<\/li>\n<li><strong>Container Analysis \/ vulnerability scanning<\/strong> capabilities (how results appear depends on artifact type and whether the artifact is stored in your project)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Primarily a <strong>software supply chain Security service<\/strong> and <strong>artifact source<\/strong> (distribution channel).<\/li>\n<li>Not a general-purpose vulnerability scanner by itself (although it may interoperate with scanning features elsewhere in Google Cloud).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scope: regional\/global and tenancy model<\/h3>\n\n\n\n<p>The service is consumed within the Google Cloud resource model:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Project-scoped access control<\/strong>: You typically control who can access artifacts via IAM at the project\/repository level (often via Artifact Registry permissions).<\/li>\n<li><strong>Location-dependent endpoints<\/strong>: Artifact repositories in Google Cloud are created in specific locations (regions or multi-regions), so consumption endpoints may be tied to a location.<\/li>\n<li><strong>Organization policy and network controls<\/strong>: In enterprises, you can use organization policies and restricted endpoints (for example, restricted Google APIs) to enforce dependency sourcing rules.<\/li>\n<\/ul>\n\n\n\n<p>Because exact availability (locations, artifact formats) can change, <strong>verify current supported locations and formats in the official docs<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the Google Cloud ecosystem<\/h3>\n\n\n\n<p>Assured Open Source Software fits as an upstream dependency source in a broader Google Cloud Security posture:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Developer workstation \/ CI<\/strong> pulls dependencies from Assured Open Source Software.<\/li>\n<li>Dependencies are assembled into artifacts and stored in <strong>Artifact Registry<\/strong>.<\/li>\n<li>Builds run in <strong>Cloud Build<\/strong> (or external CI) and deployments go to <strong>Cloud Run<\/strong> or <strong>GKE<\/strong>.<\/li>\n<li>Operations teams use <strong>Cloud Logging<\/strong>, <strong>Cloud Monitoring<\/strong>, and <strong>Cloud Audit Logs<\/strong> for governance and visibility.<\/li>\n<li>Security teams enforce policies using IAM, organization policies, and (where applicable) admission controls.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Assured Open Source Software?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Reduce breach risk<\/strong> from compromised dependencies (a high-cost class of incidents).<\/li>\n<li><strong>Improve audit readiness<\/strong> by standardizing and documenting dependency sourcing.<\/li>\n<li><strong>Lower vendor and operational risk<\/strong> by making dependency sourcing repeatable across teams.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Safer dependency ingestion<\/strong> than directly pulling from public upstreams.<\/li>\n<li><strong>More consistent builds<\/strong> when teams use standardized repositories and artifacts.<\/li>\n<li><strong>Easier pipeline integration<\/strong> in Google Cloud when paired with Artifact Registry and Cloud Build.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Central governance<\/strong>: one approach for multiple teams and projects.<\/li>\n<li><strong>Fewer \u201csnowflake\u201d build setups<\/strong>: reduces operational load and troubleshooting complexity.<\/li>\n<li><strong>Better visibility<\/strong>: central access control and audit logging for dependency pulls (depending on how you configure it).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security and compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Helps address supply-chain risks such as:<\/li>\n<li>typosquatting and dependency confusion<\/li>\n<li>compromised upstream distributions<\/li>\n<li>lag between vulnerability disclosure and patch adoption<\/li>\n<li>Can support compliance programs by strengthening controls around third-party software sourcing.<\/li>\n<li><strong>Do not assume it automatically makes you compliant<\/strong>. Compliance depends on your overall controls and evidence. Verify compliance mapping in official docs and your GRC program.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability and performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Centralized dependency sources can improve reliability versus ad-hoc upstream fetching.<\/li>\n<li>Teams can optimize caching and artifact access patterns (especially when combined with Artifact Registry strategies and CI design).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<p>Choose Assured Open Source Software when:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You want a <strong>stronger trust model<\/strong> for OSS consumption.<\/li>\n<li>You are standardizing an SDLC on Google Cloud and want to <strong>tighten supply-chain controls<\/strong>.<\/li>\n<li>You support regulated workloads and need more controlled third-party dependency sourcing.<\/li>\n<li>You have multiple teams and need consistent dependency policies.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<p>Assured Open Source Software may not be the right fit when:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You need <strong>full coverage of all OSS ecosystems<\/strong> or niche packages (Assured Open Source Software is curated, not exhaustive).<\/li>\n<li>You run fully air-gapped environments without a plan for importing artifacts.<\/li>\n<li>Your platform is not Google Cloud-centric and you cannot adopt the required integration points.<\/li>\n<li>You require guarantees that are not documented (for example, \u201call packages are supported for 10 years\u201d). <strong>Only rely on what Google explicitly documents.<\/strong><\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Assured Open Source Software used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<p>Common adoption patterns include:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Financial services and fintech (high Security scrutiny)<\/li>\n<li>Healthcare and life sciences (regulated environments)<\/li>\n<li>Public sector and defense contractors (strict supply-chain controls)<\/li>\n<li>SaaS and B2B platforms (multi-tenant Security requirements)<\/li>\n<li>E-commerce and retail (large dependency graphs, frequent releases)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform engineering teams building golden paths<\/li>\n<li>Security engineering and AppSec teams setting standards<\/li>\n<li>DevOps\/SRE teams operating CI\/CD and deployment guardrails<\/li>\n<li>Developers working in polyglot stacks (containers + language deps)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads and architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Microservices using containers (Cloud Run, GKE)<\/li>\n<li>CI\/CD pipelines with Cloud Build or third-party CI connected to Google Cloud<\/li>\n<li>Artifact-centric governance architectures (Artifact Registry as the \u201csource of truth\u201d)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Organizations that want to <strong>prevent direct internet dependency downloads<\/strong> from CI<\/li>\n<li>Enterprises using <strong>VPC Service Controls, org policies<\/strong>, and central networking controls<\/li>\n<li>Teams adopting <strong>policy-as-code<\/strong> and admission policies<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Production vs dev\/test usage<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Production<\/strong>: Most valuable where Security controls and auditability matter.<\/li>\n<li><strong>Dev\/test<\/strong>: Useful to prevent \u201cit works on my machine\u201d drift and to keep dev dependencies aligned with production policies.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic use cases for Assured Open Source Software in Google Cloud Security programs. Coverage depends on what artifact types are supported at the time you implement\u2014verify supported ecosystems in official docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Standardize container base images for all teams<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Teams pull arbitrary base images (unknown provenance, inconsistent patching).<\/li>\n<li><strong>Why this service fits:<\/strong> Assured Open Source Software provides a more controlled source of base images (where supported) and reduces reliance on random upstreams.<\/li>\n<li><strong>Example:<\/strong> A platform team mandates that all Dockerfiles use approved Assured Open Source Software base images.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Reduce dependency confusion risk in CI builds<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> CI pulls packages directly from public registries; namespace collisions can lead to dependency confusion.<\/li>\n<li><strong>Why it fits:<\/strong> You can centralize dependency sources and constrain what CI can access.<\/li>\n<li><strong>Example:<\/strong> Build jobs are locked down to fetch dependencies only from approved sources.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Create an \u201capproved OSS\u201d policy for regulated workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Regulated workloads require stronger third-party software controls and evidence.<\/li>\n<li><strong>Why it fits:<\/strong> A curated, documented source supports governance and audit narratives.<\/li>\n<li><strong>Example:<\/strong> A healthcare organization documents Assured Open Source Software as its approved dependency source for production builds.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Improve patch adoption for critical dependencies<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Teams lag behind on upgrading vulnerable dependencies.<\/li>\n<li><strong>Why it fits:<\/strong> Assured Open Source Software is designed around secure consumption and vulnerability awareness for supported artifacts.<\/li>\n<li><strong>Example:<\/strong> A security team prefers vetted builds and uses vulnerability signals to prioritize upgrades.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Build \u201cgolden pipelines\u201d for Cloud Build + Artifact Registry<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Every team invents its own build pipeline; controls are inconsistent.<\/li>\n<li><strong>Why it fits:<\/strong> Assured Open Source Software aligns with centralized artifacts and supply-chain governance.<\/li>\n<li><strong>Example:<\/strong> A shared Cloud Build template fetches dependencies from approved repositories and outputs to Artifact Registry.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Establish a controlled source for third-party runtime images in Cloud Run<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Cloud Run services use images built on unknown upstream layers.<\/li>\n<li><strong>Why it fits:<\/strong> A vetted upstream reduces surprises and supports Security baselines.<\/li>\n<li><strong>Example:<\/strong> Cloud Run services are built from approved base images and stored in Artifact Registry.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Prepare for software supply-chain audits (SBOM\/provenance discussions)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Auditors ask where dependencies come from and how you verify them.<\/li>\n<li><strong>Why it fits:<\/strong> Assured Open Source Software supports a stronger sourcing story.<\/li>\n<li><strong>Example:<\/strong> The organization demonstrates standardized dependency sourcing, repository permissions, and audit logs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Minimize direct internet access from build environments<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Builds require broad egress, increasing risk of exfiltration and supply-chain attacks.<\/li>\n<li><strong>Why it fits:<\/strong> Centralized repositories support egress restrictions and allowlisting.<\/li>\n<li><strong>Example:<\/strong> CI runs in a restricted network; only Google APIs and approved repositories are reachable.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Support multi-team monorepos with consistent dependency policy<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Monorepos with many services drift across dependencies and build patterns.<\/li>\n<li><strong>Why it fits:<\/strong> A unified upstream reduces fragmentation.<\/li>\n<li><strong>Example:<\/strong> All services in a monorepo consume dependencies from the same approved sources.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Enforce \u201conly approved artifacts deploy to production\u201d<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Teams can deploy images built from unknown dependencies.<\/li>\n<li><strong>Why it fits:<\/strong> Assured Open Source Software is one layer in an end-to-end chain of custody (source \u2192 build \u2192 registry \u2192 deploy).<\/li>\n<li><strong>Example:<\/strong> Production deployment policies require images to originate from approved registries and build processes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Build a secure internal developer platform (IDP)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Developer experience and Security often conflict.<\/li>\n<li><strong>Why it fits:<\/strong> Developers get a simple, stable way to pull dependencies that meets Security requirements.<\/li>\n<li><strong>Example:<\/strong> The IDP provides starter templates that reference approved artifact sources.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Reduce exposure to compromised upstream registries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Public registries can have outages or malicious content.<\/li>\n<li><strong>Why it fits:<\/strong> A curated alternative reduces blast radius for supply-chain events.<\/li>\n<li><strong>Example:<\/strong> A company shifts critical dependencies to a controlled source.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<p>Because Google may evolve the feature set and supported ecosystems, treat the items below as <strong>core patterns<\/strong> and confirm exact implementation details in the official docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 1: Curated set of open source artifacts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Provides access to a selected set of popular OSS artifacts rather than the entire universe of packages.<\/li>\n<li><strong>Why it matters:<\/strong> Reduces the attack surface and makes security review and maintenance more feasible.<\/li>\n<li><strong>Practical benefit:<\/strong> Teams avoid random upstreams and focus on a vetted set.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Not all packages are included; you may still need a separate process for unsupported dependencies.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 2: Google-managed distribution channel<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Artifacts are distributed through Google-managed infrastructure and workflows.<\/li>\n<li><strong>Why it matters:<\/strong> Centralization and consistent controls improve trust compared to ad-hoc mirrors.<\/li>\n<li><strong>Practical benefit:<\/strong> Better operational stability and standardized access patterns.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> You must follow Google\u2019s supported access methods and locations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 3: Security monitoring signals (vulnerability awareness)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Assists with vulnerability awareness and update practices for the supported artifacts.<\/li>\n<li><strong>Why it matters:<\/strong> Vulnerability disclosure velocity is high; you need a managed way to keep up.<\/li>\n<li><strong>Practical benefit:<\/strong> Helps teams make faster, safer upgrade decisions.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> How vulnerability data is surfaced depends on artifact type and how you store\/consume artifacts (for example, whether you mirror into your own Artifact Registry repositories).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 4: Supply-chain assurance signals (provenance-related)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> For supported artifacts, provides stronger supply-chain assurance than typical upstream consumption (for example, provenance or build-related verifiability).<\/li>\n<li><strong>Why it matters:<\/strong> Provenance and integrity are central to modern Security (SLSA-style approaches).<\/li>\n<li><strong>Practical benefit:<\/strong> You can build policies around \u201cwhere did this artifact come from?\u201d<\/li>\n<li><strong>Limitations\/caveats:<\/strong> The exact form of provenance\/attestations varies by artifact and may require specific tooling to verify. <strong>Verify in official docs<\/strong> what is provided and how to validate it.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 5: Designed to integrate with Artifact Registry and IAM<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Encourages dependency access patterns that use Google Cloud IAM and repository controls.<\/li>\n<li><strong>Why it matters:<\/strong> Security and governance require least privilege and audit logs.<\/li>\n<li><strong>Practical benefit:<\/strong> Central permission management, easier offboarding, and auditability.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> You must design repository structure and IAM carefully to avoid overbroad access.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 6: Aligns with secure CI\/CD patterns<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Works well with Cloud Build and artifact-first pipelines.<\/li>\n<li><strong>Why it matters:<\/strong> The strongest supply-chain control is end-to-end: source \u2192 build \u2192 artifact storage \u2192 deploy.<\/li>\n<li><strong>Practical benefit:<\/strong> Better traceability and fewer \u201cunknown builds.\u201d<\/li>\n<li><strong>Limitations\/caveats:<\/strong> If you use third-party CI, you must still implement equivalent controls and identity federation.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<p>Assured Open Source Software typically sits at the \u201cdependency ingestion\u201d stage:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Developers\/CI pull dependencies from Assured Open Source Software.<\/li>\n<li>Your build system (often Cloud Build) compiles\/builds your application.<\/li>\n<li>Built artifacts are stored in Artifact Registry (your project).<\/li>\n<li>Deployment systems (Cloud Run \/ GKE) deploy artifacts from Artifact Registry.<\/li>\n<li>Security teams enforce controls with IAM, policies, and monitoring.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/data\/control flow (conceptual)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control plane:<\/strong> IAM policies, repository settings, org policies, audit logs.<\/li>\n<li><strong>Data plane:<\/strong> Artifact download (dependency pulls), artifact uploads (build outputs), runtime image pulls by Cloud Run\/GKE.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related Google Cloud services<\/h3>\n\n\n\n<p>Common integrations include:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Artifact Registry<\/strong>: repository management and access control<\/li>\n<li><strong>Cloud Build<\/strong>: building images\/binaries in a controlled environment<\/li>\n<li><strong>Cloud Logging \/ Cloud Monitoring<\/strong>: observability for build and deploy<\/li>\n<li><strong>Cloud Audit Logs<\/strong>: access trails for repository and admin actions<\/li>\n<li><strong>Security Command Center (SCC)<\/strong>: organizational Security posture (how Assured Open Source Software signals show up depends on configuration; verify in docs)<\/li>\n<li><strong>Binary Authorization<\/strong> (primarily for GKE): enforce admission policies based on attestation and trusted images (verify applicability for your environment)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud APIs for Artifact Registry and builds<\/li>\n<li>Identity and Access Management (IAM)<\/li>\n<li>Networking: Google APIs access (public or restricted endpoints)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Identity:<\/strong> Google Cloud IAM identities (users, groups, service accounts)<\/li>\n<li><strong>AuthN:<\/strong> OAuth2 tokens issued by Google; Docker credential helper via <code>gcloud auth configure-docker<\/code><\/li>\n<li><strong>AuthZ:<\/strong> IAM roles on projects and Artifact Registry repositories<\/li>\n<li><strong>Auditability:<\/strong> Admin and data access logs (depending on your Cloud Audit Logs configuration)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Dependency pulls and artifact operations go through Google APIs.<\/li>\n<li>Enterprises can:<\/li>\n<li>restrict egress at the VPC layer<\/li>\n<li>use private access patterns (for example, Private Google Access and\/or restricted.googleapis.com) depending on architecture<\/li>\n<li>enforce \u201conly approved endpoints\u201d for builds<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Track:<\/li>\n<li>repository access events (who pulled what and when)<\/li>\n<li>build provenance (which pipeline produced what)<\/li>\n<li>vulnerability management workflows for produced images<\/li>\n<li>Use:<\/li>\n<li>Cloud Audit Logs for repository and API actions<\/li>\n<li>Cloud Logging for Cloud Build logs<\/li>\n<li>Artifact Registry UI\/metadata for artifact inspection<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  Dev[Developer \/ CI] --&gt;|Pull vetted deps| AOSS[Assured Open Source Software]\n  Dev --&gt;|Build app| CB[Cloud Build]\n  CB --&gt;|Push image| AR[Artifact Registry (project repo)]\n  AR --&gt;|Deploy image| CR[Cloud Run or GKE]\n  AR --&gt; AL[Cloud Audit Logs]\n  CB --&gt; CL[Cloud Logging]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Org[Google Cloud Organization]\n    OP[Org Policies \/ Governance]\n    IAM[IAM: Groups, SAs, Least Privilege]\n    VPCSC[VPC Service Controls (optional)]\n  end\n\n  subgraph Build[CI\/CD]\n    Dev[Dev Workstations]\n    CI[CI System: Cloud Build or External CI]\n    WIF[Workload Identity Federation (optional)]\n  end\n\n  subgraph SupplyChain[Dependency &amp; Artifact Layer]\n    AOSS[Assured Open Source Software]\n    AR[Artifact Registry]\n    CA[Container Analysis \/ Vulnerability Signals\\n(availability depends on artifact type)]\n  end\n\n  subgraph Runtime[Runtime]\n    CR[Cloud Run]\n    GKE[GKE]\n    BA[Binary Authorization (GKE)]\n  end\n\n  subgraph Observability[Operations &amp; Security Ops]\n    LOG[Cloud Logging]\n    MON[Cloud Monitoring]\n    AUD[Cloud Audit Logs]\n    SCC[Security Command Center\\n(verify integrations)]\n  end\n\n  OP --&gt; IAM\n  IAM --&gt; CI\n  VPCSC -. restrict .-&gt; CI\n\n  Dev --&gt; CI\n  WIF -. identity .-&gt; CI\n\n  CI --&gt;|Pull approved deps| AOSS\n  CI --&gt;|Publish build outputs| AR\n  AR --&gt; CA\n\n  AR --&gt;|Deploy| CR\n  AR --&gt;|Deploy| GKE\n  BA -. enforce .-&gt; GKE\n\n  CI --&gt; LOG\n  AR --&gt; AUD\n  CI --&gt; AUD\n  CA --&gt; SCC\n  LOG --&gt; SCC\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<p>Because Assured Open Source Software access and supported artifact types can vary, confirm prerequisites in the official documentation before you begin.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Google Cloud account and project<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A Google Cloud account with a billing-enabled project.<\/li>\n<li>Ability to enable required APIs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>You typically need:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>To manage APIs and project config:<\/li>\n<li><code>roles\/serviceusage.serviceUsageAdmin<\/code> (or equivalent)<\/li>\n<li>\n<p><code>roles\/resourcemanager.projectIamAdmin<\/code> (if you manage IAM)<\/p>\n<\/li>\n<li>\n<p>For Artifact Registry:<\/p>\n<\/li>\n<li>Admin tasks: <code>roles\/artifactregistry.admin<\/code><\/li>\n<li>Read-only tasks: <code>roles\/artifactregistry.reader<\/code><\/li>\n<li>\n<p>Writing\/pushing: <code>roles\/artifactregistry.writer<\/code><\/p>\n<\/li>\n<li>\n<p>For Cloud Build and Cloud Run (if you use them in the lab):<\/p>\n<\/li>\n<li><code>roles\/cloudbuild.builds.editor<\/code> (or finer-grained)<\/li>\n<li><code>roles\/run.admin<\/code> and <code>roles\/iam.serviceAccountUser<\/code> (for deploying)<\/li>\n<li>Service account permissions used by Cloud Build and Cloud Run<\/li>\n<\/ul>\n\n\n\n<p>Use least privilege in production and prefer group-based assignment.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Assured Open Source Software itself may not have a direct usage fee, but you will incur costs for:<\/li>\n<li>Artifact Registry storage and egress<\/li>\n<li>Cloud Build build minutes<\/li>\n<li>Cloud Run\/GKE runtime<\/li>\n<li>Logging and monitoring volumes<br\/>\n<strong>Verify pricing in official docs and pricing pages.<\/strong><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">CLI\/SDK\/tools needed<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Shell (recommended) or local installation:<\/li>\n<li><code>gcloud<\/code> CLI<\/li>\n<li>Docker (Cloud Shell includes Docker; local setups vary)<\/li>\n<li>Optional:<\/li>\n<li><code>cosign<\/code> or other tooling if you plan to verify signatures\/attestations (only if officially supported for your artifact type; verify in docs)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Artifact Registry repositories are location-specific (region or multi-region).<\/li>\n<li>Assured Open Source Software artifact endpoints may be available only in certain locations.<\/li>\n<li><strong>Verify current supported locations<\/strong> in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Artifact Registry quotas (requests, storage)<\/li>\n<li>Cloud Build quotas (concurrent builds, build minutes)<\/li>\n<li>Cloud Run quotas (instances, requests)\nCheck quotas in the Google Cloud console and plan for scale.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services (APIs)<\/h3>\n\n\n\n<p>For the lab in this tutorial:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Artifact Registry API<\/li>\n<li>Cloud Build API<\/li>\n<li>Cloud Run API (optional, if deploying)<\/li>\n<li>Container Scanning\/Analysis APIs may be involved depending on your use and current Google Cloud behavior; verify in docs.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<p>Assured Open Source Software should be analyzed from a cost perspective as part of an end-to-end supply-chain setup. The costs you pay are usually <strong>not for \u201cAssured Open Source Software\u201d directly<\/strong>, but for the services you use to store, build, scan, and run artifacts.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (typical)<\/h3>\n\n\n\n<p>Verify current pricing and SKUs in official sources. Common pricing dimensions you\u2019ll encounter:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Artifact Registry<\/strong>\n   &#8211; Storage (GB-month)\n   &#8211; Data egress (network transfer out, if applicable)\n   &#8211; Requests\/operations (some services price by operations; verify Artifact Registry\u2019s current model)\n   &#8211; Official pricing: https:\/\/cloud.google.com\/artifact-registry\/pricing<\/p>\n<\/li>\n<li>\n<p><strong>Cloud Build<\/strong>\n   &#8211; Build minutes\/compute used (with free tier and paid tiers depending on current pricing)\n   &#8211; Official pricing: https:\/\/cloud.google.com\/build\/pricing<\/p>\n<\/li>\n<li>\n<p><strong>Cloud Run<\/strong> (if you deploy)\n   &#8211; vCPU, memory, requests, and networking\n   &#8211; Official pricing: https:\/\/cloud.google.com\/run\/pricing<\/p>\n<\/li>\n<li>\n<p><strong>Logging\/Monitoring<\/strong>\n   &#8211; Log ingestion and retention beyond free allocations\n   &#8211; Official pricing: https:\/\/cloud.google.com\/stackdriver\/pricing (Cloud Operations pricing page; verify current URL if it changes)<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Many Google Cloud services include free tiers (Cloud Build, Cloud Run, Logging allocations).<\/li>\n<li>Assured Open Source Software may not have a \u201cfree tier\u201d concept if it is not billed directly.<\/li>\n<li><strong>Always confirm current free tier limits and whether they apply to your region and account type.<\/strong><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost drivers<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Number and size of images\/packages you pull and store<\/li>\n<li>Frequency of builds (CI volume)<\/li>\n<li>How many environments you deploy to (dev\/stage\/prod)<\/li>\n<li>Network egress to on-prem or other clouds<\/li>\n<li>Retention policies for artifacts and logs<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden or indirect costs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Artifact sprawl<\/strong>: storing many image versions can quietly grow storage bills.<\/li>\n<li><strong>Verbose build logs<\/strong>: high-volume logs can exceed free ingestion.<\/li>\n<li><strong>Cross-region traffic<\/strong>: pulling artifacts across regions can incur network costs.<\/li>\n<li><strong>Duplicated dependencies<\/strong>: if each project mirrors its own set, you may pay repeatedly.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network\/data transfer implications<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Pulling artifacts into a runtime environment in a different region or outside Google Cloud can incur egress.<\/li>\n<li>Prefer colocating:<\/li>\n<li>Artifact Registry location<\/li>\n<li>Cloud Build region (where applicable)<\/li>\n<li>Cloud Run\/GKE region<br\/>\n  to reduce latency and egress.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use lifecycle policies and retention limits for Artifact Registry (where supported) to delete old versions.<\/li>\n<li>Centralize common base images in shared projects (with careful IAM).<\/li>\n<li>Avoid rebuilding unchanged dependencies; use build caching where appropriate.<\/li>\n<li>Control log verbosity and set retention policies appropriately.<\/li>\n<li>Use the Google Cloud Pricing Calculator:<\/li>\n<li>https:\/\/cloud.google.com\/products\/calculator<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (conceptual)<\/h3>\n\n\n\n<p>A minimal learning setup might include:\n&#8211; 1 Artifact Registry Docker repository\n&#8211; A few pulled and pushed images totaling a few GB\n&#8211; A handful of Cloud Build runs\n&#8211; Optional: a single Cloud Run service with low traffic<\/p>\n\n\n\n<p>You would typically see costs primarily from:\n&#8211; Artifact Registry storage (small)\n&#8211; Cloud Build minutes (often within free tier for light usage)\n&#8211; Cloud Run compute (often within free tier for light usage)<br\/>\n<strong>Do not assume $0<\/strong>; use the calculator and confirm your account\u2019s free tier eligibility.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>In production, consider:\n&#8211; Hundreds\/thousands of builds per day (Cloud Build compute cost)\n&#8211; Many image versions retained (Artifact Registry storage cost)\n&#8211; Multi-region deployments (replication, egress, operations overhead)\n&#8211; Logging volume from CI\/CD and runtime\n&#8211; Additional Security tooling (SCC tiers, third-party scanners) if used<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<p>This lab focuses on a practical and low-cost pattern: <strong>select an Assured Open Source Software container image, mirror it into your own Artifact Registry repository for governance, build a small app using it, and optionally deploy to Cloud Run<\/strong>.<\/p>\n\n\n\n<p>Because the exact catalog entries and pull commands can change, the lab uses a safe approach:\n&#8211; You will <strong>copy the official pull reference<\/strong> from the Assured Open Source Software catalog\/documentation in your Google Cloud console.\n&#8211; You will not rely on hard-coded image paths that might become outdated.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Locate an Assured Open Source Software container image reference.<\/li>\n<li>Pull it in Cloud Shell.<\/li>\n<li>Push (mirror) it into your own Artifact Registry repo for traceability and access control.<\/li>\n<li>Build a small container image using Cloud Build.<\/li>\n<li>(Optional) Deploy to Cloud Run.<\/li>\n<li>Validate outcomes and clean up.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will create:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>One Artifact Registry Docker repository in your project<\/li>\n<li>One app container image built in Cloud Build<\/li>\n<li>Optionally one Cloud Run service<\/li>\n<\/ul>\n\n\n\n<p>You will also:\n&#8211; Authenticate Docker to Artifact Registry\n&#8211; Use Cloud Audit Logs \/ console views for verification<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Expected cost<\/h4>\n\n\n\n<p>Low, but not guaranteed free. Main cost drivers: Artifact Registry storage, Cloud Build minutes, Cloud Run usage (if deployed).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Set up project, region, and APIs<\/h3>\n\n\n\n<p>1) Open <strong>Cloud Shell<\/strong> in the Google Cloud Console.<\/p>\n\n\n\n<p>2) Set variables:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export PROJECT_ID=\"$(gcloud config get-value project)\"\nexport REGION=\"us-central1\"\nexport REPO=\"aoss-lab\"\nexport SERVICE_NAME=\"aoss-demo\"\n<\/code><\/pre>\n\n\n\n<p>If <code>PROJECT_ID<\/code> is empty, set it:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud config set project YOUR_PROJECT_ID\nexport PROJECT_ID=\"YOUR_PROJECT_ID\"\n<\/code><\/pre>\n\n\n\n<p>3) Enable required APIs:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services enable \\\n  artifactregistry.googleapis.com \\\n  cloudbuild.googleapis.com \\\n  run.googleapis.com\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> APIs enable successfully.<br\/>\n<strong>Verification:<\/strong> In the console, go to <strong>APIs &amp; Services \u2192 Enabled APIs &amp; services<\/strong> and confirm.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Identify an Assured Open Source Software image to use<\/h3>\n\n\n\n<p>You need a container image reference published via Assured Open Source Software.<\/p>\n\n\n\n<p>1) In the Google Cloud Console, search for <strong>\u201cAssured Open Source Software\u201d<\/strong> (sometimes shown as <strong>Assured OSS<\/strong>).<\/p>\n\n\n\n<p>2) Browse the catalog and select an image you want to use as a base (for example, a common OS\/base image or runtime image offered by Assured Open Source Software).<\/p>\n\n\n\n<p>3) Copy the <strong>exact pull reference<\/strong> (including registry host\/path and tag or digest).<\/p>\n\n\n\n<p>4) Set it as an environment variable in Cloud Shell:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export AOSS_BASE_IMAGE=\"PASTE_THE_EXACT_ASSURED_OSS_IMAGE_REFERENCE_HERE\"\n<\/code><\/pre>\n\n\n\n<p>Example format (do not copy this as-is; use the value from the console\/docs):\n&#8211; <code>LOCATION-docker.pkg.dev\/...\/IMAGE:TAG<\/code>\n&#8211; or <code>...@sha256:DIGEST<\/code><\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> You have a valid Assured Open Source Software image reference in <code>AOSS_BASE_IMAGE<\/code>.<br\/>\n<strong>Verification:<\/strong> Print it:<\/p>\n\n\n\n<pre><code class=\"language-bash\">echo \"$AOSS_BASE_IMAGE\"\n<\/code><\/pre>\n\n\n\n<p>If you cannot find the catalog or don\u2019t have access, stop here and review prerequisites. Access may depend on your organization setup. <strong>Verify in official docs<\/strong> how to enable the service for your org\/project.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create an Artifact Registry repository for mirroring<\/h3>\n\n\n\n<p>Create a Docker repository in Artifact Registry:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud artifacts repositories create \"$REPO\" \\\n  --repository-format=docker \\\n  --location=\"$REGION\" \\\n  --description=\"Lab repo for mirroring Assured Open Source Software images\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Repository is created.<br\/>\n<strong>Verification:<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud artifacts repositories describe \"$REPO\" --location=\"$REGION\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Authenticate Docker to Artifact Registry<\/h3>\n\n\n\n<p>Configure Docker credential helper for Artifact Registry:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud auth configure-docker \"${REGION}-docker.pkg.dev\" --quiet\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Docker is configured to authenticate to Artifact Registry in the selected region.<br\/>\n<strong>Verification:<\/strong> You should see a message indicating Docker config has been updated.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Pull the Assured Open Source Software image and mirror it into your repo<\/h3>\n\n\n\n<p>1) Pull the selected Assured Open Source Software image:<\/p>\n\n\n\n<pre><code class=\"language-bash\">docker pull \"$AOSS_BASE_IMAGE\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Image downloads successfully.<br\/>\n<strong>Verification:<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">docker images | head\n<\/code><\/pre>\n\n\n\n<p>2) Tag it for your Artifact Registry repo:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export MIRROR_IMAGE=\"${REGION}-docker.pkg.dev\/${PROJECT_ID}\/${REPO}\/aoss-base:lab\"\ndocker tag \"$AOSS_BASE_IMAGE\" \"$MIRROR_IMAGE\"\n<\/code><\/pre>\n\n\n\n<p>3) Push to your repository:<\/p>\n\n\n\n<pre><code class=\"language-bash\">docker push \"$MIRROR_IMAGE\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> The mirrored image is stored in your project\u2019s Artifact Registry repository.<br\/>\n<strong>Verification (CLI):<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud artifacts docker images list \"${REGION}-docker.pkg.dev\/${PROJECT_ID}\/${REPO}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Verification (Console):<\/strong>\n&#8211; Go to <strong>Artifact Registry \u2192 Repositories \u2192 aoss-lab \u2192 Images<\/strong> and confirm <code>aoss-base<\/code> exists.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Build a small demo image using Cloud Build<\/h3>\n\n\n\n<p>Create a simple web server using the mirrored base image.<\/p>\n\n\n\n<p>1) Create a working directory:<\/p>\n\n\n\n<pre><code class=\"language-bash\">mkdir -p ~\/aoss-demo &amp;&amp; cd ~\/aoss-demo\n<\/code><\/pre>\n\n\n\n<p>2) Create a minimal app (using a tiny HTTP server in Python as an example).<br\/>\nIf your selected base image does not include Python, adjust the example accordingly. The point of the lab is the workflow (consume Assured Open Source Software \u2192 mirror \u2192 build).<\/p>\n\n\n\n<p>Create <code>app.py<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-python\">from http.server import BaseHTTPRequestHandler, HTTPServer\n\nclass Handler(BaseHTTPRequestHandler):\n    def do_GET(self):\n        self.send_response(200)\n        self.send_header(\"Content-Type\", \"text\/plain; charset=utf-8\")\n        self.end_headers()\n        self.wfile.write(b\"Hello from a container built with an Assured Open Source Software base image.\\n\")\n\nif __name__ == \"__main__\":\n    HTTPServer((\"0.0.0.0\", 8080), Handler).serve_forever()\n<\/code><\/pre>\n\n\n\n<p>3) Create a <code>Dockerfile<\/code> that uses your mirrored base image:<\/p>\n\n\n\n<pre><code class=\"language-Dockerfile\">FROM us-central1-docker.pkg.dev\/PROJECT\/REPO\/aoss-base:lab\nWORKDIR \/app\nCOPY app.py \/app\/app.py\nEXPOSE 8080\nCMD [\"python3\", \"\/app\/app.py\"]\n<\/code><\/pre>\n\n\n\n<p>Now replace the <code>FROM<\/code> line with your mirrored image reference:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sed -i \"s|FROM .*|FROM ${MIRROR_IMAGE}|\" Dockerfile\n<\/code><\/pre>\n\n\n\n<p>4) Build and push with Cloud Build:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export APP_IMAGE=\"${REGION}-docker.pkg.dev\/${PROJECT_ID}\/${REPO}\/aoss-demo-app:v1\"\ngcloud builds submit --tag \"$APP_IMAGE\" .\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Cloud Build builds the container and pushes it to Artifact Registry.<br\/>\n<strong>Verification:<\/strong>\n&#8211; In Cloud Shell:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud artifacts docker images list \"${REGION}-docker.pkg.dev\/${PROJECT_ID}\/${REPO}\"\n<\/code><\/pre>\n\n\n\n<ul class=\"wp-block-list\">\n<li>In the console:<\/li>\n<li><strong>Cloud Build \u2192 History<\/strong> shows a successful build.<\/li>\n<li><strong>Artifact Registry \u2192 aoss-lab<\/strong> shows <code>aoss-demo-app<\/code>.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7 (Optional): Deploy to Cloud Run<\/h3>\n\n\n\n<p>Deploy the image:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud run deploy \"$SERVICE_NAME\" \\\n  --image \"$APP_IMAGE\" \\\n  --region \"$REGION\" \\\n  --allow-unauthenticated\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Cloud Run deploys the service and prints a URL.<br\/>\n<strong>Verification:<\/strong>\n&#8211; Visit the URL in your browser; you should see:<\/p>\n\n\n\n<pre><code>Hello from a container built with an Assured Open Source Software base image.\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Use this checklist:<\/p>\n\n\n\n<p>1) <strong>Artifact Registry contains mirrored base image<\/strong>\n&#8211; Repo list shows <code>aoss-base:lab<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud artifacts docker images list \"${REGION}-docker.pkg.dev\/${PROJECT_ID}\/${REPO}\"\n<\/code><\/pre>\n\n\n\n<p>2) <strong>Cloud Build succeeded<\/strong>\n&#8211; Cloud Build History shows a successful run.<\/p>\n\n\n\n<p>3) <strong>Cloud Run (if deployed) serves traffic<\/strong>\n&#8211; The service URL returns expected text.<\/p>\n\n\n\n<p>4) <strong>Auditability<\/strong>\n&#8211; In the console:\n  &#8211; <strong>Logging \u2192 Logs Explorer<\/strong>\n  &#8211; Filter Cloud Build logs by build ID, or Artifact Registry access logs (availability depends on your Audit Logs configuration).<\/p>\n\n\n\n<p>If you want to explore vulnerability-related views:\n&#8211; In Artifact Registry, select your image and look for vulnerability\/metadata tabs.<br\/>\nHow vulnerabilities are displayed depends on current Google Cloud scanning behavior and your configuration. <strong>Verify in official docs<\/strong> if you need a guaranteed scanning workflow for your artifact type.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p><strong>Issue: <code>docker pull<\/code> fails with permission denied<\/strong>\n&#8211; Confirm you have access to the Assured Open Source Software artifact reference you copied.\n&#8211; If the artifact requires authentication, ensure you are logged in:\n  &#8211; <code>gcloud auth login<\/code>\n  &#8211; <code>gcloud auth application-default login<\/code> (sometimes needed for certain tools)\n&#8211; Re-run:\n  &#8211; <code>gcloud auth configure-docker \"${REGION}-docker.pkg.dev\" --quiet<\/code><\/p>\n\n\n\n<p><strong>Issue: Cannot find Assured Open Source Software in the console<\/strong>\n&#8211; It may require org enablement, allowlisting, or a specific entitlement.\n&#8211; Check:\n  &#8211; official docs: https:\/\/cloud.google.com\/assured-open-source-software\/docs\n  &#8211; your organization\u2019s Security\/admin team for enablement steps<\/p>\n\n\n\n<p><strong>Issue: Cloud Build fails because <code>python3<\/code> is missing<\/strong>\n&#8211; Your selected base image may not include Python.\n&#8211; Options:\n  &#8211; Pick an Assured Open Source Software base image that contains the runtime you need.\n  &#8211; Modify the lab to use a different runtime (e.g., Node, Java) based on what your base image supports.\n  &#8211; Use a multi-stage Docker build (advanced) to add only what you need.<\/p>\n\n\n\n<p><strong>Issue: Cloud Run deploy fails due to permissions<\/strong>\n&#8211; Ensure your user has <code>roles\/run.admin<\/code> and <code>roles\/iam.serviceAccountUser<\/code>.\n&#8211; If using a custom service account, grant it permissions to pull from Artifact Registry:\n  &#8211; <code>roles\/artifactregistry.reader<\/code> on the repo\/project.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing costs, delete resources created in this lab.<\/p>\n\n\n\n<p>1) Delete Cloud Run service (if created):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud run services delete \"$SERVICE_NAME\" --region \"$REGION\" --quiet\n<\/code><\/pre>\n\n\n\n<p>2) Delete Artifact Registry repository (deletes images too):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud artifacts repositories delete \"$REPO\" --location=\"$REGION\" --quiet\n<\/code><\/pre>\n\n\n\n<p>3) (Optional) Disable APIs if this was a temporary project:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services disable run.googleapis.com cloudbuild.googleapis.com artifactregistry.googleapis.com --quiet\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Centralize dependency sourcing<\/strong>: define a standard way for all teams to consume approved OSS (Assured Open Source Software where supported).<\/li>\n<li><strong>Separate concerns by project<\/strong>:<\/li>\n<li>shared \u201cplatform\u201d project for base images and shared artifacts (with strict IAM)<\/li>\n<li>per-team projects for application artifacts<\/li>\n<li><strong>Prefer immutable references<\/strong> (digests) for production build inputs when supported, to avoid \u201cmoving tags\u201d risk.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM \/ Security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>least privilege<\/strong>:<\/li>\n<li>CI service account: reader access to dependency repos, writer access to output repos<\/li>\n<li>Developers: reader access, limited writer access where necessary<\/li>\n<li>Use <strong>group-based IAM<\/strong> (Google Groups \/ Cloud Identity) rather than user-by-user grants.<\/li>\n<li>Use <strong>separate service accounts per pipeline<\/strong> to isolate blast radius.<\/li>\n<li>Protect admin roles (<code>artifactregistry.admin<\/code>, project IAM admins) with strong controls (MFA, approvals).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Create artifact retention and cleanup policies:<\/li>\n<li>keep only N versions per service<\/li>\n<li>delete old build artifacts that are not deployed<\/li>\n<li>Avoid cross-region pulls and pushes.<\/li>\n<li>Monitor:<\/li>\n<li>Artifact Registry storage growth<\/li>\n<li>Cloud Build minutes and concurrency<\/li>\n<li>Logging ingestion<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Co-locate build, registry, and runtime in the same region when possible.<\/li>\n<li>Use caching patterns (where supported) in CI to avoid repeated downloads and rebuilds.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Treat your artifact strategy as critical infrastructure:<\/li>\n<li>define repository naming conventions and access patterns<\/li>\n<li>have a rollback plan using previous artifact versions<\/li>\n<li>Keep base image upgrades controlled and tested; roll out via staged environments.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Turn on and retain relevant <strong>Cloud Audit Logs<\/strong> for artifact access and admin changes.<\/li>\n<li>Standardize:<\/li>\n<li>repo naming (<code>platform-base<\/code>, <code>team-apps<\/code>, <code>prod-images<\/code>)<\/li>\n<li>tagging strategy (<code>v1.2.3<\/code>, <code>gitsha-...<\/code>, environment tags)<\/li>\n<li>Use dashboards\/alerts for:<\/li>\n<li>build failures<\/li>\n<li>deploy failures<\/li>\n<li>unusual artifact pull patterns<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use labels\/tags to record:<\/li>\n<li>owning team<\/li>\n<li>environment<\/li>\n<li>application name<\/li>\n<li>data classification (if applicable)<\/li>\n<li>If you mirror artifacts, record metadata (in documentation or tagging conventions) about source and verification steps.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<p>Assured Open Source Software is a Security control, but it must be part of a larger secure SDLC.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Control access through IAM:<\/li>\n<li>Who can pull approved dependencies?<\/li>\n<li>Who can publish artifacts?<\/li>\n<li>Who can administer repositories?<\/li>\n<li>Prefer service accounts for automation; avoid long-lived user credentials in CI.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>In transit: TLS to Google APIs.<\/li>\n<li>At rest: Google-managed encryption by default in supported services (Artifact Registry, Cloud Build logs).<\/li>\n<li>For stronger control, evaluate CMEK where supported by the underlying services (Artifact Registry supports CMEK in some contexts; verify in official docs for your location and repo type).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Reduce dependency on open internet:<\/li>\n<li>restrict egress from CI environments<\/li>\n<li>use approved endpoints for pulling dependencies<\/li>\n<li>Consider restricted Google APIs endpoints for regulated environments (implementation depends on your networking model).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Do not store registry credentials in plaintext.<\/li>\n<li>Use:<\/li>\n<li>service account identities<\/li>\n<li>short-lived tokens<\/li>\n<li>Secret Manager for any required secrets (if applicable)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable and retain:<\/li>\n<li>Cloud Audit Logs for Artifact Registry and Cloud Build<\/li>\n<li>Cloud Build logs and deployment logs<\/li>\n<li>Regularly review:<\/li>\n<li>who accessed which repositories<\/li>\n<li>unusual pull patterns (potential data exfil or compromised credentials)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Assured Open Source Software can support compliance goals by strengthening third-party software controls.<\/li>\n<li>You still need:<\/li>\n<li>documented processes<\/li>\n<li>evidence collection<\/li>\n<li>separation of duties<\/li>\n<li>change management<br\/>\n  Do not treat any single service as \u201ccompliance done.\u201d<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Allowing direct dependency pulls from the internet in CI alongside Assured Open Source Software (defeats the point).<\/li>\n<li>Using broad IAM roles (e.g., granting admin to many users).<\/li>\n<li>Not pinning dependencies (tags that move, unbounded semver ranges).<\/li>\n<li>No retention strategy: old vulnerable images remain available and get reused.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use artifact immutability practices:<\/li>\n<li>pin by digest for production deployments where possible<\/li>\n<li>keep a promotion pipeline (dev \u2192 stage \u2192 prod) that promotes the same artifact<\/li>\n<li>Combine with policy:<\/li>\n<li>allowlist registries<\/li>\n<li>enforce that production deploys only from approved Artifact Registry projects<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<p>Because Assured Open Source Software is curated and may be entitlement-based, the biggest \u201cgotchas\u201d are often around scope and availability.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Coverage is not universal:<\/strong> Not every OSS dependency will be available.<\/li>\n<li><strong>Artifact types may vary:<\/strong> Containers vs language packages vs OS packages\u2014verify what is supported now.<\/li>\n<li><strong>Location constraints:<\/strong> Endpoints may be available only in certain Artifact Registry locations.<\/li>\n<li><strong>Access constraints:<\/strong> You may need org\/project enablement to see the catalog or access certain repositories.<\/li>\n<li><strong>Scanning expectations:<\/strong> Vulnerability data display depends on whether artifacts are stored in your project and on current scanning behavior. Don\u2019t assume \u201ceverything is scanned and visible everywhere.\u201d<\/li>\n<li><strong>Mirroring changes semantics:<\/strong> If you copy an image into your own repo, you improve governance, but you may not automatically preserve all upstream metadata in the way you expect. Validate how provenance\/signatures apply in your workflow.<\/li>\n<li><strong>Build reproducibility isn\u2019t automatic:<\/strong> Using a better upstream helps, but you still need pinned versions, deterministic builds, and controlled build environments.<\/li>\n<li><strong>Cost surprises:<\/strong> Artifact storage growth and cross-region egress can be non-obvious.<\/li>\n<li><strong>Migration challenges:<\/strong> Moving from \u201cpublic registry everywhere\u201d to controlled sources can break builds; plan phased adoption and developer enablement.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Assured Open Source Software is one approach to supply-chain Security. In practice, teams combine multiple controls.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Comparison table<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Assured Open Source Software (Google Cloud)<\/strong><\/td>\n<td>Teams wanting a curated, more trusted OSS source in Google Cloud<\/td>\n<td>Stronger sourcing model; integrates with Google Cloud artifact + IAM patterns<\/td>\n<td>Curated coverage; may require enablement; exact supported ecosystems vary<\/td>\n<td>When standardizing OSS consumption in Google Cloud with stronger assurances<\/td>\n<\/tr>\n<tr>\n<td><strong>Artifact Registry alone<\/strong><\/td>\n<td>General artifact storage and governance<\/td>\n<td>Strong IAM, audit logs, lifecycle management, regional control<\/td>\n<td>Doesn\u2019t automatically solve upstream trust; you still need a trusted source<\/td>\n<td>When you already have secure upstreams or you mirror and govern carefully<\/td>\n<\/tr>\n<tr>\n<td><strong>Binary Authorization (GKE)<\/strong><\/td>\n<td>Enforcing deploy-time policy for containers in GKE<\/td>\n<td>Strong admission control; enforces attestations and trusted images<\/td>\n<td>GKE-specific; doesn\u2019t source dependencies by itself<\/td>\n<td>When you need strict \u201conly verified images run\u201d enforcement on GKE<\/td>\n<\/tr>\n<tr>\n<td><strong>Container Analysis \/ scanning features<\/strong><\/td>\n<td>Detecting known vulnerabilities<\/td>\n<td>Helps identify CVEs and prioritize fixes<\/td>\n<td>Detection is not prevention; depends on scanning coverage<\/td>\n<td>When you need vulnerability visibility on stored artifacts<\/td>\n<\/tr>\n<tr>\n<td><strong>Self-managed internal mirror (e.g., Nexus\/Artifactory)<\/strong><\/td>\n<td>Multi-cloud or on-prem heavy environments<\/td>\n<td>Full control, can mirror everything, mature enterprise features<\/td>\n<td>You operate it; patching\/availability is on you; trust model is still yours<\/td>\n<td>When you need portability and broad ecosystem coverage with internal ops capacity<\/td>\n<\/tr>\n<tr>\n<td><strong>GitHub Dependabot \/ Renovate<\/strong><\/td>\n<td>Dependency update automation<\/td>\n<td>Great developer workflow; PR-based upgrades<\/td>\n<td>Doesn\u2019t provide a trusted artifact source; relies on upstream registries<\/td>\n<td>When your main gap is upgrade automation rather than artifact sourcing<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS CodeArtifact<\/strong><\/td>\n<td>AWS-native artifact management<\/td>\n<td>Good AWS integration, IAM-based access<\/td>\n<td>Different ecosystem; not Google Cloud<\/td>\n<td>When your platform is primarily AWS<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Artifacts<\/strong><\/td>\n<td>Azure DevOps-centric teams<\/td>\n<td>Integrated with Azure DevOps pipelines<\/td>\n<td>Different ecosystem; not Google Cloud<\/td>\n<td>When you are standardized on Azure DevOps<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example (regulated multi-team platform)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A regulated enterprise has 50+ teams deploying microservices to GKE and Cloud Run. Builds pull dependencies directly from public registries, and Security audits repeatedly flag weak supply-chain controls.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Assured Open Source Software as an approved upstream for selected OSS artifacts<\/li>\n<li>Artifact Registry as the centralized artifact store<\/li>\n<li>Cloud Build as the standard build platform (or integrated external CI with federated identity)<\/li>\n<li>Policies:<ul>\n<li>CI egress restrictions so builds can\u2019t fetch arbitrary internet dependencies<\/li>\n<li>IAM least privilege on repositories<\/li>\n<li>Binary Authorization on GKE to ensure only artifacts from approved repos deploy (where applicable)<\/li>\n<\/ul>\n<\/li>\n<li>Observability:<ul>\n<li>Cloud Audit Logs retained for repository access and admin actions<\/li>\n<li>Logging and Monitoring dashboards for build\/deploy failures and unusual access<\/li>\n<\/ul>\n<\/li>\n<li><strong>Why Assured Open Source Software was chosen:<\/strong><\/li>\n<li>Provides a clearer and more defensible dependency sourcing story for audits<\/li>\n<li>Aligns with Google Cloud native artifact and identity controls<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Reduced dependency-source risk<\/li>\n<li>Standardized build patterns<\/li>\n<li>Improved audit evidence and faster Security reviews<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup \/ small-team example (fast shipping, limited Security headcount)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A startup ships weekly and uses many OSS dependencies. They had a scare with a compromised dependency and want better controls without building a full Security program from scratch.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Use Assured Open Source Software for the most important base images\/dependencies (where supported)<\/li>\n<li>Store application images in Artifact Registry<\/li>\n<li>Use Cloud Build triggers for builds and Cloud Run for deployment<\/li>\n<li>Keep a simple policy: production services must deploy only from the team\u2019s Artifact Registry repo<\/li>\n<li><strong>Why Assured Open Source Software was chosen:<\/strong><\/li>\n<li>Faster to adopt than building an internal mirror and vetting program<\/li>\n<li>Good fit for Google Cloud-native workflow<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Lower risk from upstream dependency compromise<\/li>\n<li>Better consistency across builds<\/li>\n<li>Minimal operational overhead<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is Assured Open Source Software the same as Artifact Registry?<\/strong><br\/>\nNo. Artifact Registry is a repository service for storing and managing artifacts. Assured Open Source Software is about <strong>trusted sourcing of selected OSS artifacts<\/strong>, often consumed through Google Cloud artifact workflows.<\/p>\n\n\n\n<p>2) <strong>Does Assured Open Source Software include every open source package?<\/strong><br\/>\nNo. It is typically a curated set. Verify the supported packages\/ecosystems in the official docs.<\/p>\n\n\n\n<p>3) <strong>Do I still need vulnerability scanning if I use Assured Open Source Software?<\/strong><br\/>\nOften yes. Better sourcing reduces risk, but you still need vulnerability management, patching, and runtime controls.<\/p>\n\n\n\n<p>4) <strong>Is Assured Open Source Software free?<\/strong><br\/>\nAssured Open Source Software may not be billed as a standalone SKU, but you will pay for related services you use (Artifact Registry, Cloud Build, Cloud Run, networking). Verify current pricing details in official docs.<\/p>\n\n\n\n<p>5) <strong>Can I use it outside Google Cloud?<\/strong><br\/>\nPossibly, depending on how artifacts are accessed and licensing\/entitlements, but the best integration story is within Google Cloud. Verify supported access patterns in official docs.<\/p>\n\n\n\n<p>6) <strong>Does it solve dependency confusion?<\/strong><br\/>\nIt can help by standardizing and controlling dependency sources, but you must also configure package managers, repository priorities, and CI network controls correctly.<\/p>\n\n\n\n<p>7) <strong>Should I pin by tag or digest?<\/strong><br\/>\nFor production, pinning by digest is often preferred for immutability where supported. Use tags for human readability but ensure your deployment process is deterministic.<\/p>\n\n\n\n<p>8) <strong>How do I prove developers used Assured Open Source Software?<\/strong><br\/>\nUse:\n&#8211; repository access logs (Cloud Audit Logs)\n&#8211; build configuration reviews (Cloud Build configs)\n&#8211; policy enforcement (restrict egress; allowlist registries)<\/p>\n\n\n\n<p>9) <strong>Does mirroring an Assured Open Source Software image into my repo reduce its assurance?<\/strong><br\/>\nMirroring improves governance and access control, but you must validate how provenance\/signatures apply post-copy. Test your verification workflow and consult official guidance.<\/p>\n\n\n\n<p>10) <strong>Can I enforce that builds only pull from approved sources?<\/strong><br\/>\nYes, typically via:\n&#8211; CI egress restrictions\n&#8211; using only internal\/approved repositories\n&#8211; organization policies and guardrails<br\/>\nExact implementation depends on your network and CI design.<\/p>\n\n\n\n<p>11) <strong>Is Assured Open Source Software a replacement for SBOM tooling?<\/strong><br\/>\nNot necessarily. It\u2019s a sourcing control. SBOM generation\/management may still be required for your compliance and Security workflows.<\/p>\n\n\n\n<p>12) <strong>What\u2019s the main operational effort?<\/strong><br\/>\nDesigning:\n&#8211; repository structure and IAM\n&#8211; build templates and guardrails\n&#8211; update and patching workflows for base images\/dependencies<\/p>\n\n\n\n<p>13) <strong>Can I use it with external CI like GitHub Actions?<\/strong><br\/>\nUsually yes, using secure identity federation or service account keys (keys are not recommended). Prefer Workload Identity Federation where possible; verify patterns in official docs.<\/p>\n\n\n\n<p>14) <strong>How do I roll out across many teams?<\/strong><br\/>\nStart with:\n&#8211; a platform \u201cgolden path\u201d\n&#8211; templates and example repos\n&#8211; staged enforcement (warn \u2192 block)\n&#8211; training and developer enablement<\/p>\n\n\n\n<p>15) <strong>What\u2019s the fastest way to get started?<\/strong><br\/>\nUse the lab approach in this tutorial:\n&#8211; pick one Assured Open Source Software artifact\n&#8211; mirror it into your repo\n&#8211; build one service from it\n&#8211; then standardize via templates<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Assured Open Source Software<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official product page<\/td>\n<td>https:\/\/cloud.google.com\/assured-open-source-software<\/td>\n<td>High-level overview and positioning within Google Cloud Security<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>https:\/\/cloud.google.com\/assured-open-source-software\/docs<\/td>\n<td>Authoritative configuration, supported ecosystems, and current workflows<\/td>\n<\/tr>\n<tr>\n<td>Artifact management docs<\/td>\n<td>https:\/\/cloud.google.com\/artifact-registry\/docs<\/td>\n<td>Practical repository setup, IAM patterns, and artifact operations used with Assured Open Source Software<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>https:\/\/cloud.google.com\/artifact-registry\/pricing<\/td>\n<td>Core cost driver for storing\/mirroring artifacts<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>https:\/\/cloud.google.com\/build\/pricing<\/td>\n<td>Cloud Build cost model for CI pipelines<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>https:\/\/cloud.google.com\/run\/pricing<\/td>\n<td>Cloud Run cost model if you deploy workloads<\/td>\n<\/tr>\n<tr>\n<td>Supply-chain guidance<\/td>\n<td>https:\/\/cloud.google.com\/docs\/security<\/td>\n<td>Entry point for Google Cloud Security concepts and related services<\/td>\n<\/tr>\n<tr>\n<td>SLSA reference<\/td>\n<td>https:\/\/slsa.dev\/<\/td>\n<td>Background on provenance and supply-chain levels (conceptual grounding)<\/td>\n<\/tr>\n<tr>\n<td>OSV database<\/td>\n<td>https:\/\/osv.dev\/<\/td>\n<td>Understand vulnerability identifiers and ecosystem vulnerability data (commonly referenced in OSS security workflows)<\/td>\n<\/tr>\n<tr>\n<td>Google Cloud Tech (videos)<\/td>\n<td>https:\/\/www.youtube.com\/@googlecloudtech<\/td>\n<td>Talks and demos; search within channel for \u201cAssured OSS\u201d and \u201csoftware supply chain\u201d<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, SREs, platform teams<\/td>\n<td>DevOps, CI\/CD, Cloud, Security fundamentals<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Beginners to intermediate DevOps learners<\/td>\n<td>SCM, DevOps foundations, tooling<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud operations and platform roles<\/td>\n<td>Cloud ops, SRE-style operations<\/td>\n<td>Check website<\/td>\n<td>https:\/\/cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, production operations teams<\/td>\n<td>SRE practices, reliability, incident response<\/td>\n<td>Check website<\/td>\n<td>https:\/\/sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops teams exploring AIOps<\/td>\n<td>AIOps concepts, operations automation<\/td>\n<td>Check website<\/td>\n<td>https:\/\/aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps \/ Cloud training content<\/td>\n<td>Beginners to advanced practitioners<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps tooling and CI\/CD training<\/td>\n<td>DevOps engineers, students<\/td>\n<td>https:\/\/devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Practical DevOps help and enablement<\/td>\n<td>Small teams needing hands-on guidance<\/td>\n<td>https:\/\/devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support and operational training<\/td>\n<td>Ops teams and engineers<\/td>\n<td>https:\/\/devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting<\/td>\n<td>Architecture, CI\/CD, cloud migrations<\/td>\n<td>Standardizing Artifact Registry and CI pipelines; operationalizing secure SDLC patterns<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps and cloud consulting\/training<\/td>\n<td>Platform engineering, pipeline design, skills enablement<\/td>\n<td>Designing golden pipelines; rolling out org-wide build standards; training teams on secure artifact practices<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting services<\/td>\n<td>CI\/CD, automation, operational improvements<\/td>\n<td>CI hardening, repository governance, build\/deploy standardization<\/td>\n<td>https:\/\/devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before this service<\/h3>\n\n\n\n<p>To use Assured Open Source Software effectively, you should understand:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Basics of Google Cloud projects, IAM, and service accounts<\/li>\n<li>Artifact concepts: container registries, package repositories, versioning<\/li>\n<li>CI\/CD fundamentals (build, test, artifact, deploy)<\/li>\n<li>Basic container knowledge (Dockerfile, image tags\/digests)<\/li>\n<li>Security basics: least privilege, audit logs, supply-chain threats<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after this service<\/h3>\n\n\n\n<p>To build a mature supply-chain Security program on Google Cloud:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Artifact Registry governance at scale (multi-project strategies)<\/li>\n<li>Cloud Build secure builds, build isolation, and provenance concepts<\/li>\n<li>Policy enforcement:<\/li>\n<li>Binary Authorization (for GKE)<\/li>\n<li>org policy constraints<\/li>\n<li>Vulnerability management workflows and patch SLAs<\/li>\n<li>SBOM and provenance verification tooling (only what\u2019s officially supported for your artifact types)<\/li>\n<li>Network security for CI (egress restriction patterns)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud security engineer<\/li>\n<li>Platform engineer \/ internal developer platform engineer<\/li>\n<li>DevSecOps engineer<\/li>\n<li>SRE (especially CI\/CD and release engineering)<\/li>\n<li>Cloud solution architect<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (if available)<\/h3>\n\n\n\n<p>Assured Open Source Software itself is not typically a standalone certification topic, but it aligns with:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud Security Engineer learning paths<\/li>\n<li>Professional Cloud DevOps Engineer learning paths<br\/>\nVerify current Google Cloud certification tracks: https:\/\/cloud.google.com\/learn\/certification<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build a \u201csecure base image pipeline\u201d:<\/li>\n<li>consume an Assured Open Source Software base image<\/li>\n<li>mirror it internally<\/li>\n<li>build sample apps from it<\/li>\n<li>enforce usage via templates<\/li>\n<li>Create a multi-team Artifact Registry layout with least-privilege IAM.<\/li>\n<li>Implement CI egress controls so builds can only reach approved artifact sources.<\/li>\n<li>Track and rotate base images across services with staged rollouts.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Assured Open Source Software:<\/strong> A Google Cloud Security offering providing a more trusted channel for consuming selected open source artifacts (often abbreviated \u201cAssured OSS\u201d).<\/li>\n<li><strong>Artifact Registry:<\/strong> Google Cloud service for storing and managing container images and packages with IAM-based access control.<\/li>\n<li><strong>Supply chain security:<\/strong> Controls that reduce risk from third-party components across source, build, storage, and deployment.<\/li>\n<li><strong>Dependency confusion:<\/strong> A class of attacks where a build system fetches a malicious package from an unexpected registry due to naming\/priority issues.<\/li>\n<li><strong>Typosquatting:<\/strong> Malicious packages published with names similar to popular dependencies.<\/li>\n<li><strong>Provenance:<\/strong> Metadata describing how an artifact was built and from what sources (conceptual; exact availability depends on artifact type and tooling).<\/li>\n<li><strong>Digest:<\/strong> Immutable hash reference for a container image (<code>@sha256:...<\/code>), safer than mutable tags.<\/li>\n<li><strong>CI\/CD:<\/strong> Continuous integration and continuous delivery\/deployment pipelines.<\/li>\n<li><strong>IAM:<\/strong> Identity and Access Management; controls who can do what in Google Cloud.<\/li>\n<li><strong>Cloud Audit Logs:<\/strong> Logs that record admin activity and data access for Google Cloud services (subject to configuration and log type).<\/li>\n<li><strong>Least privilege:<\/strong> Granting only the minimum access needed to perform a task.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Assured Open Source Software is a Google Cloud Security service focused on <strong>safer consumption of open source software<\/strong> through a more trusted, curated artifact source and supply-chain assurance patterns. It fits best when you want to reduce upstream dependency risk and standardize dependency sourcing across teams using Google Cloud-native tooling like Artifact Registry and Cloud Build.<\/p>\n\n\n\n<p>Cost-wise, the biggest drivers are usually <strong>Artifact Registry storage\/egress<\/strong>, <strong>Cloud Build minutes<\/strong>, and runtime costs (Cloud Run\/GKE) rather than a direct Assured Open Source Software line item\u2014confirm the current pricing model in official docs. Security-wise, it improves your posture only when combined with <strong>least-privilege IAM, controlled CI egress, pinned dependencies, audit logging, and policy enforcement<\/strong>.<\/p>\n\n\n\n<p>Use Assured Open Source Software when you need a practical, scalable way to strengthen OSS supply-chain controls in Google Cloud. Next, deepen your implementation by standardizing repository layout, CI templates, and enforcement policies, and by validating provenance\/vulnerability workflows using the official documentation: https:\/\/cloud.google.com\/assured-open-source-software\/docs<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Security<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[51,10],"tags":[],"class_list":["post-792","post","type-post","status-publish","format-standard","hentry","category-google-cloud","category-security"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/792","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=792"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/792\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=792"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=792"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=792"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}