Pillars of Creation — automated security scanning in every build
The problem this solves
In a typical setup, developers discover CVEs at audit time — security scanning is a separate step, often manual, often skipped under deadline pressure. By the time a finding lands in a report, the image that triggered it is already running in production.
SmoothGlue's Pillars of Creation pipeline runs automated scans at every stage — before the image reaches any registry. No developer configuration required for apps onboarded through the Console.
The four pillars
The pipeline runs four pillars in sequence. Pillars 2 and 3 gate: if Critical findings are detected, the build fails before promotion.
Pillar 1 — Pipeline Trigger
Activates on every commit to a merge request or default branch. Downloads and caches dependencies. Framework detection happens here — the pipeline identifies your project type automatically (Node.js, Java, Python, C++) and activates the relevant build jobs.
Pillar 2 — Code Analysis & Artifact Build
Scans source code before building anything. All analysis jobs run in parallel in the code-analyze stage. The pipeline only proceeds to artifact-build if no Critical findings are detected.
Pillar 3 — Artifact Analysis
Scans the built artifact before it's published. Static and dynamic analysis run in parallel in the artifact-analyze stage.
Syft never blocks — it attaches the SBOM to the pipeline as an artifact. All other static tools block on Critical findings. Dynamic analysis blocks if tests fail.
Pillar 4 — GitLab Local Registry
Publishes artifacts only after all previous stages pass.
The BoE is the audit trail your ISSO needs for ATO evidence packages. It's produced automatically on every passing pipeline.
What you don't configure
For apps onboarded through the Console, the Pillars pipeline is pre-wired to your GitLab repo. There is no scanner to install, no registry credentials to provide, and no security thresholds to set — those are platform defaults.
You can view every pillar's results in GitLab → CI/CD → Pipelines → [run] → Jobs.
If you need to integrate the pipeline into an existing repo that wasn't created through the Console, see Use the Pillars pipeline in your project →.
How to read a pipeline failure
Pillar 2 failure — code analysis
The pipeline fails at the code-analyze stage. Common causes:
Stage: code-analyze FAILED
TruffleHog: High-entropy string found in src/config.js (line 42)
Possible secret: API_KEY = "AKIA..."
Fix: Remove the credential, rotate it immediately, rewrite git history
Developer action: Remove the secret from the file AND from git history. A secret that was committed — even briefly — must be rotated. Push and the pipeline retries.
Pillar 3 failure — artifact analysis
The pipeline fails at the artifact-analyze stage. Grype and Trivy report independently:
Stage: artifact-analyze FAILED
Grype: CVE-2024-XXXXX CRITICAL openssl 3.0.2 Fixed in: 3.0.7
Component: openssl
Fix: Upgrade base image or openssl package to >= 3.0.7
Developer action: Update the dependency or base image to the fix version, push to the branch, and the pipeline re-runs automatically. If no fix version exists yet, your ISSO must sign off on risk acceptance — this is not a unilateral developer decision.
What you still own
Your code's posture. Semgrep catches known patterns — business logic vulnerabilities, custom cryptography misuse, and architecture-level issues are yours to find.
CVE risk acceptance decisions. When a Critical CVE has no available fix, the ISSO must review and accept residual risk in writing. SmoothGlue provides the evidence (Grype + Trivy reports + SBOM); the acceptance decision is yours.
License compliance. Syft generates the SBOM with license information for every package. Reviewing license flags (GPL-licensed dependencies in a proprietary product, for example) is your responsibility.
Functional correctness. Cypress and unit tests run if defined in your project. Writing meaningful tests is your responsibility — the pipeline executes whatever tests exist.