In this section
Pillars of Creation — builds, analysis, and delivery
The problem this solves
Pillars of Creation provides shared GitLab CI/CD jobs for building software, analyzing source and artifacts, collecting evidence, and publishing releases. Projects include the shared pipeline and configure the integrations their application needs.
The four pillars
The four pillars group related responsibilities. They are not four GitLab stage names or a guarantee that every project runs every scanner.
Pillar 1 — Pipeline trigger
Workflow rules determine whether GitLab creates a pipeline. The shared configuration supports merge requests, tags, the default branch, and other sources, with rules that avoid duplicate push pipelines when a merge request is open.
Framework includes select jobs using project files and explicit switches. Supported integrations include npm, Gradle, pip, Poetry, Go, CMake, and .NET. A selected framework still needs its expected project configuration and build commands.
Pillar 2 — Code analysis and artifact build
Framework jobs prepare dependencies and build application code. Source-analysis jobs include tools such as MegaLinter, Semgrep, TruffleHog, and SonarQube, subject to their activation rules and required configuration.
The pipeline declares code-build before code-analyze. Some analysis jobs use
needs: [], which lets them start without waiting for earlier stages. Do not assume
that all source analysis finishes before any build work begins.
The container-image job uses Buildah to build and push a container image during
artifact-build. Later scanners read the image from that registry. Registry presence
alone does not establish that an image passed analysis or is approved for deployment.
Pillar 3 — Artifact analysis
Artifact-analysis jobs inspect the built image, generate software bills of materials (SBOMs), and run the tests or integrations enabled for the project. Jobs can be skipped when their required inputs are absent or their switches are disabled.
Failure behavior is specific to the tool and pipeline context:
| Check | Configured behavior |
|---|---|
| Grype | The job sets GRYPE_FAIL_ON_SEVERITY to high; applicable overrides can change the effective setting. |
| Syft | Generates SBOM files. It has no vulnerability-severity gate, but an execution error can still fail its job. |
| Other scanners | Use their own commands, thresholds, credentials, and job rules. They do not share a universal Critical-only threshold. |
| Shared failure rules | Applicable jobs block in merge-request and protected-ref contexts; other branch contexts can allow failures. Upstream pipeline context can also affect the result. |
A successful pipeline can contain skipped jobs or allowed failures. Review the jobs that actually ran and their effective configuration before interpreting the result.
Pillar 4 — GitLab local registry
The pipeline uses GitLab registries and job artifacts for delivery and evidence. Container images are already pushed during artifact build. Language packages, Helm charts, evidence archives, and release attachments have their own publication jobs and activation conditions.
The software-bill-of-material and body-of-evidence jobs package collected output.
Their default publication rules provide manual jobs on tags, with additional rules
for release pipelines. They are not guaranteed to create archives on every passing
branch pipeline.
Pipeline stages
The shared pipeline declares these stages. Individual job dependencies and rules control the actual execution order and whether each stage contains work.
| Stage | Purpose |
|---|---|
dependencies | Prepare framework dependencies. |
code-build | Build application code with the selected framework. |
code-analyze | Analyze source code and configuration. |
artifact-build | Build distributable artifacts, including container images. |
artifact-analyze | Analyze artifacts and run configured tests. |
publish | Run applicable package, evidence-archive, and publication jobs. |
evidence | Reserved for additional evidence jobs; the shared archive jobs use publish. |
deploy | Provide a stage for deployment jobs added by the consuming project. |
sync | Run configured synchronization work. |
release | Create releases and attach applicable artifacts. |
What to configure
A consuming project needs access to the shared pipeline and suitable runners. Integrations can require additional settings, including SonarQube configuration, scanner service credentials, release permissions, or downstream-project access.
Use the onboarding guide to add the pipeline to an existing project. Use the configuration reference to identify the settings for your workflow.
How to read a pipeline failure
Pillar 2 failure — code analysis
Open the failed job and inspect its log and retained evidence. Determine whether the failure is a finding, an invalid configuration, unavailable credentials, or a tool execution error. Fix the cause and rerun the applicable job or pipeline.
For a committed credential, revoke or rotate the exposed credential using your team's incident procedure. Removing the visible text alone does not invalidate the credential.
Pillar 3 failure — artifact analysis
Read the scanner's affected package, installed version, severity, and any reported fixed version. Verify that the findings belong to the image reference used by this pipeline. Update the dependency or base image when an appropriate fix is available.
Use your organization's review process when a finding requires an exception. A job marked as an allowed failure does not itself constitute risk acceptance.
What you still own
Your team owns application tests, interpretation of findings, integration configuration, and deployment approval. The pipeline executes the checks that are selected and configured; it cannot establish the correctness of untested application behavior.
Keep the SBOM and scan evidence associated with the relevant build. Review license metadata and vulnerability findings according to your organization's requirements.