Revert "St0rmz1/feature/use securebuild for builds (#319)" (#326)

This reverts commit 7cde42e.

Author: laverya

.github/workflows/publish.yml

@@ -75,7 +75,6 @@ jobs:
       - uses: dagger/[email protected]
         id: dagger-publish
         env:
-          USE_SECUREBUILD: true
           OP_SERVICE_ACCOUNT: ${{ secrets.OP_SERVICE_ACCOUNT }}
           OP_SERVICE_ACCOUNT_PRODUCTION: ${{ secrets.OP_SERVICE_ACCOUNT_PRODUCTION }}
         with:
@@ -100,7 +99,6 @@ jobs:
       - uses: dagger/[email protected]
         id: dagger-publish
         env:
-          USE_SECUREBUILD: true
           OP_SERVICE_ACCOUNT: ${{ secrets.OP_SERVICE_ACCOUNT }}
           OP_SERVICE_ACCOUNT_PRODUCTION: ${{ secrets.OP_SERVICE_ACCOUNT_PRODUCTION }}
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

certs/README.md

@@ -1,60 +1,36 @@
 # Certificates and Verification Tools
 
-> **⚠️ DEPRECATION NOTICE**: This directory is transitioning away from manual image verification tools as SecureBuild now automatically handles SLSA attestations, SBOM generation, and image signing for staging and production builds. See migration notes below.
+This directory contains certificates and verification tools used for validating the authenticity and integrity of Replicated SDK container images.
 
-This directory contains legacy certificates and verification tools that were used for validating the authenticity and integrity of Replicated SDK container images.
-
-## 🔄 Migration to SecureBuild
-
-**As of September 2025**, the Replicated SDK build pipeline uses [SecureBuild](https://securebuild.com) for staging and production image builds, which provides:
-
-- **Automatic SLSA Attestation**: Built-in provenance generation without manual workflows
-- **Automatic SBOM Generation**: Comprehensive software bill of materials with CVE remediation data
-- **Automatic Image Signing**: Cryptographic signatures managed by SecureBuild
-- **Multi-Registry Publishing**: Images published to Docker Hub, Replicated registries, and CVE0.io
-
-### Current Build Architecture
-
-- **Development Builds**: May still use traditional pipeline with manual verification (optional SecureBuild)
-- **Staging/Production Builds**: Use SecureBuild with automatic security attestations
-- **Environment Flag**: Controlled by `USE_SECUREBUILD=true` in GitHub Actions
-
-## 📋 Legacy Contents (For Reference)
+## Contents
 
 ### Verification Script
-- `verify-image.sh` - **Legacy script** for manual SLSA attestation, image signatures, and SBOM verification
+- `verify-image.sh` - Script to verify SLSA attestation, image signatures, and SBOM for SDK images
 
 ### Public Keys
-- `cosign-dev.pub` - **Legacy**: Development environment public key for image signature verification
-- `cosign-stage.pub` - **Legacy**: Staging environment public key for image signature verification  
-- `cosign-prod.pub` - **Legacy**: Production environment public key for image signature verification
-
-## 🔧 Verification Methods
+- `cosign-dev.pub` - Development environment public key for image signature verification
+- `cosign-stage.pub` - Staging environment public key for image signature verification
+- `cosign-prod.pub` - Production environment public key for image signature verification
 
-### For SecureBuild Images (Recommended)
-SecureBuild images include built-in attestations and can be verified using SecureBuild's verification tools. Refer to the [SecureBuild documentation](https://securebuild.com) for current verification methods.
+## Usage
 
-### For Legacy Images (Development/Fallback)
-If using traditional pipeline builds, the legacy verification script can still be used:
+The verification script supports three environments (dev, stage, prod) and can be run as follows:
 
 ```bash
 ./verify-image.sh --env <environment> --version <version> --digest <image-digest>
 ```
 
-For detailed usage instructions:
+For detailed usage instructions and examples, run:
 ```bash
 ./verify-image.sh --help
 ```
 
-## ⚠️ Important Notes
+## Environment-Specific Verification
 
-1. **Production Images**: All production images now use SecureBuild attestations - legacy verification may not apply
-2. **Staging Images**: All staging images now use SecureBuild attestations - legacy verification may not apply  
-3. **Development Images**: May use either SecureBuild or legacy pipeline depending on `USE_SECUREBUILD` flag
-4. **Future Plans**: This directory may be removed in future releases once SecureBuild migration is complete
+- **Development**: Uses `cosign-dev.pub` for signature verification
+- **Staging**: Uses `cosign-stage.pub` for signature verification
+- **Production**: Uses `cosign-prod.pub` for signature verification
 
-## 📚 Documentation References
+## Security Notes
 
-- **Current Build Process**: See `/dagger/README.md` for comprehensive SecureBuild integration guide
-- **SecureBuild Benefits**: Zero-CVE images, enhanced security, compliance-ready attestations
-- **Migration Guide**: All GitHub Actions workflows automatically use SecureBuild for staging/production
+- The public keys in this directory are used only for verification

dagger.json

@@ -1,6 +1,6 @@
 {
   "name": "replicated-sdk",
-  "engineVersion": "v0.18.14",
+  "engineVersion": "v0.18.6",
   "sdk": {
     "source": "go"
   },

dagger/.gitignore

@@ -2,4 +2,3 @@
 /internal/dagger
 /internal/querybuilder
 /internal/telemetry
-/.env

dagger/README.md

@@ -1,40 +1,5 @@
 # Dagger Pipeline Usage
 
-## Build Architecture Overview
-
-This Dagger pipeline supports two build approaches:
-
-### 🚀 **SecureBuild** (Default for staging/production)
-- **What**: Zero-CVE container images built by SecureBuild.com
-- **Benefits**: Enhanced security, compliance, automatic CVE remediation
-- **Requirements**: SecureBuild account + 1Password access
-- **Registries**: Docker Hub + Replicated registries + CVE0.io
-
-### 🛠️ **Wolfi/TTL.sh** (Fallback for development)  
-- **What**: Traditional Wolfi-based images for development
-- **Benefits**: No credentials required
-- **Requirements**: None (public repositories only)
-- **Registries**: TTL.sh 
-
----
-
-## 🔧 **Environment Configuration**
-
-### SecureBuild Mode (Recommended)
-```bash
-export USE_SECUREBUILD=true
-export OP_SERVICE_ACCOUNT="your-1password-service-account-token"
-export OP_SERVICE_ACCOUNT_PRODUCTION="your-production-1password-token"  # for production builds
-```
-
-### Traditional Mode (Development Fallback)
-```bash
-# No environment variables needed - will use deploy/apko-wolfi.yaml
-# Images published to ttl.sh with 24h expiration
-```
-
----
-
 ## Validation
 
 To validate the codebase without publishing:
@@ -45,133 +10,47 @@ dagger call validate --progress=plain \
 
 ## Publishing
 
-The publish pipeline supports different environments and configurations:
-
-> **Note**: All version numbers in examples below (e.g., `1.0.0-dev.1`, `1.0.0-beta.1`, `1.0.0`) are for illustration purposes only. Use your actual release version numbers when running commands.
+The publish pipeline supports different environments and configurations. Here are the common usage patterns:
 
 ### Development Release (ttl.sh)
 
-#### Option 1: SecureBuild Development (with credentials)
-In this scenario, the pipeline uses SecureBuild and will publish the image to ttl.sh
+For local testing using ttl.sh registry:
 ```bash
-export USE_SECUREBUILD=true
 dagger call publish --progress=plain \
     --op-service-account=env:OP_SERVICE_ACCOUNT \
     --dev=true \
     --staging=false \
-    --version=1.0.0-dev.1 \
+    --version=1.6.0-dev.1 \
     --slsa=false
 ```
-**Result**: Uses `deploy/apko-securebuild.yaml` → publishes to TTL.sh + CVE0.io
-In this scenario, the pipeline uses Wolfi and will publish to ttl.sh
-
-#### Option 2: Traditional Wolfi Development (no credentials) 
-```bash
-# DO NOT set USE_SECUREBUILD
-dagger call publish --progress=plain \
-    --op-service-account=env:OP_SERVICE_ACCOUNT \
-    --dev=true \
-    --staging=false \
-    --version=1.0.0-dev.1 \
-    --slsa=false
-```  
-**Result**: Uses `deploy/apko-wolfi.yaml` → publishes to TTL.sh only
 
-### Staging Release (SecureBuild Required)
+### Staging Release
 
 For publishing to staging environment:
 ```bash
-export USE_SECUREBUILD=true  # Required for staging builds
 dagger call publish --progress=plain \
     --op-service-account=env:OP_SERVICE_ACCOUNT \
     --op-service-account-production=env:OP_SERVICE_ACCOUNT_PRODUCTION \
     --dev=false \
     --staging=true \
-    --version=1.0.0-beta.1
+    --version=1.6.0-beta.5 \
+    --slsa=true \
+    --github-token=env:GITHUB_TOKEN
 ```
-**Result**: Uses SecureBuild staging → publishes to:
-- `docker.io/replicated/replicated-sdk:1.0.0-beta.1`
-- `registry.staging.replicated.com/library/replicated-sdk-image:1.0.0-beta.1`  
-- `cve0.io/replicated-sdk:1.0.0-beta.1`
 
-### Production Release (SecureBuild Required)
+### Production Release
 
 For publishing to production:
 ```bash
-export USE_SECUREBUILD=true  # Required for production builds
 dagger call publish --progress=plain \
     --op-service-account=env:OP_SERVICE_ACCOUNT \
     --op-service-account-production=env:OP_SERVICE_ACCOUNT_PRODUCTION \
     --dev=false \
     --staging=false \
-    --version=1.0.0
+    --version=1.6.0 \
+    --slsa=true \
+    --github-token=env:GITHUB_TOKEN
 ```
-**Result**: Uses SecureBuild production → publishes to:
-- `docker.io/replicated/replicated-sdk:1.0.0`
-- `registry.replicated.com/library/replicated-sdk-image:1.0.0`
-- `cve0.io/replicated-sdk:1.0.0`
-
-> **Note**: SecureBuild automatically handles SLSA attestations and SBOM generation, so `--slsa` and `--github-token` flags are not required (and are ignored) when using SecureBuild.
-
----
-
-## 🔐 **SecureBuild Integration**
-
-### Requirements for SecureBuild
-1. **SecureBuild Account**: Active account at SecureBuild.com
-2. **Team Configuration**:
-   - Feature flags enabled for "Custom APKO Upload" and "Custom Melange Upload"
-   - Team subscribed to the image/catalog item in SecureBuild
-3. **1Password Access**: Service account tokens for dev/production vaults
-4. **Credentials**: Proper 1Password items configured:
-   - `SecureBuild-Dev-Token` (in developer automation vault)
-   - `SecureBuild-Replicated-SDK-Prod-Token` (in production vault)
-
-### SecureBuild Benefits
-- **Zero CVE Images**: Automatically patched base images
-- **Multi-Registry Publishing**: Single build → multiple registries  
-- **Enhanced Security**: SLSA attestations + SBOM generation
-- **Compliance Ready**: Meets enterprise security requirements
-
-### Image Naming Architecture
-SecureBuild handles different registry naming requirements:
-- **Docker Hub**: Uses `replicated-sdk` image name
-- **Replicated Registries**: Uses `replicated-sdk-image` image name  
-- **CVE0.io**: Uses `replicated-sdk` image name
-
-This ensures compatibility with existing Docker Hub users and Replicated Helm charts.
-
-### Configuration Files
-- **SecureBuild**: Uses `deploy/apko-securebuild.yaml`
-- **Traditional**: Uses `deploy/apko-wolfi.yaml`
-- **Selection**: Automatic based on `USE_SECUREBUILD` environment variable
-
-### Current Limitations
-**Package Dependency Requirement**: The SecureBuild pipeline dynamically modifies the APKO configuration:
-- Version substitution: `VERSION: 1.0.0` → `VERSION: "your-version"`
-- Package substitution: `- replicated` → `- replicated-your-version`
-
-**Important**: The versioned package (e.g., `replicated-1.0.0-beta.1`) must already exist in the CVE0.io repository before the APKO build. The current pipeline does not automatically create these packages via melange submission.
-
-### Troubleshooting SecureBuild
-Common issues and solutions:
-
-**403 Forbidden Errors**:
-- Check 1Password service account has vault access
-- Verify SecureBuild team has "Custom APKO Upload" feature flag
-- Confirm API tokens are valid in 1Password items
-
-**Missing Package Errors**:  
-- SecureBuild uses CVE0.io repository for packages
-- Package `replicated-{version}` must exist before APKO build
-- **Current workaround**: Manually create packages in SecureBuild before running builds
-- **Future enhancement**: Automatic melange.yaml submission for package generation
-
-**Build Timeouts**:
-- Monitor build status in SecureBuild dashboard
-- Check Dagger traces for detailed timing
-
----
 
 ## Available Flags
 
@@ -181,19 +60,19 @@ Common issues and solutions:
 - `--dev`: (boolean) Use development environment (ttl.sh)
 - `--staging`: (boolean) Use staging environment
 - `--version`: Version string for the release
-- `--slsa`: (boolean) Enable SLSA provenance generation *(ignored when using SecureBuild)*
-- `--github-token`: GitHub token for SLSA workflow access *(ignored when using SecureBuild)*
+- `--slsa`: (boolean) Enable SLSA provenance generation
+- `--github-token`: GitHub token for SLSA workflow access
 
-**Note**: When using SecureBuild (`USE_SECUREBUILD=true`), SLSA attestations and SBOM generation are automatic. The `--slsa` and `--github-token` flags are only used with the traditional Chainguard pipeline.
+Note: SLSA provenance generation requires both `--slsa=true` and a valid `--github-token`.
 
 ## SBOM Generation
 
 Software Bill of Materials (SBOM) is automatically generated during the build process:
 
 1. **Generation Method**: 
-   - **SecureBuild**: Automatically generates comprehensive SBOMs with CVE remediation data
-   - **Traditional**: Uses Chainguard's melange and apko to create SPDX-formatted SBOMs
-   - SBOMs include all direct and transitive dependencies with license information
+   - Uses Chainguard's melange and apko to create SPDX-formatted SBOMs
+   - SBOMs are generated for both the base image and application layers
+   - Includes all direct and transitive dependencies
 
 2. **SBOM Format**:
    - Format: SPDX JSON
@@ -204,25 +83,33 @@ Software Bill of Materials (SBOM) is automatically generated during the build pr
      - Creation metadata
 
 3. **Verification**:
-   - Refer to the instructions at securebuild.com
+   - SBOMs are signed using cosign
+   - Attestations are attached to the container image
+   - Use the verification script in `certs/verify-image.sh` to verify:
+     - SLSA provenance
+     - Image signatures
+     - SBOM attestations
+   ```bash
+   ./certs/verify-image.sh --env <dev|stage|prod> --version <version> --digest <image-digest>
+   ```
 
 4. **Viewing SBOM**:
-   - Refer to the instructions at securebuild.com
-
-5. **Image Attestation**
-   - Refer to the instructions at securebuild.com
-
----
-
-## 🔄 **Migration Notes**
-
-### GitHub Actions Integration
-As of September 2025, GitHub Actions workflows automatically use SecureBuild for staging and production builds:
-- **Environment Variable**: `USE_SECUREBUILD=true` is set in `.github/workflows/publish.yml`
-- **Backward Compatibility**: Wolfi based pipeline remains as fallback if flag is removed
-- **No Breaking Changes**: All existing interfaces and outputs remain unchanged
-
-### For Contributors  
-- **Development builds**: Can still use TTL.sh without any SecureBuild credentials
-- **No setup required**: Traditional Wolfi builds work without configuration
-- **Optional SecureBuild**: Set `USE_SECUREBUILD=true` only if you have access
+   - Full SBOM content can be viewed using the `--show-sbom` flag with verify-image.sh:
+     ```bash
+     ./certs/verify-image.sh --env <dev|stage|prod> --version <version> --digest <image-digest> --show-sbom
+     ```
+
+## Image Attestation
+
+- Images pushed to Dockerhub are attested using cosign
+- This provides an additional layer of verification for public images
+- The attestation includes:
+  - SBOM data
+  - Build provenance
+  - Image signatures
+
+For production releases, SLSA provenance is automatically generated:
+- Triggered by the Dagger pipeline during production releases
+- Requires a GitHub token with permissions to trigger the SLSA workflow (`slsa.yml`)
+- The workflow is triggered via GitHub API to generate and attach provenance to the image
+- This step is skipped for development and staging releases