DevOps & Cloud Trends

Silsila Pipeline: Artifact Evidence and Kubernetes Admission Controls

Review Silsila's supply-chain blueprint, distinguishing SBOMs, signatures, admission policy and runtime detection from demonstrated regulatory compliance.

Silsila Pipeline: Artifact Evidence and Kubernetes Admission Controls

The Silsila Hardened Pipeline is a software-delivery blueprint connecting scanning, dependency inventory, signing, admission policy and runtime observation.

Those are distinct controls. Their presence in a repository does not establish an unbroken verified delivery chain or compliance with a financial-sector framework.

Know what the SBOM describes

The reviewed SBOM script runs Syft against the working directory and signs the resulting file with Cosign sign-blob. That is different from inventorying a final container image and attaching a signed attestation to its immutable digest.

Decide which artifact the inventory represents. Record its identifier, generation tool and format, then verify that the inventory can be associated with the deployed artifact.

The script's comment names CycloneDX 1.5, but an unversioned output option should not be assumed to produce that exact schema on every tool version. Pin or validate the format required by the downstream consumer.

Verify the trust boundary

A signature can establish that a trusted key or identity signed particular content. It does not prove that the content has no vulnerabilities or that the build process was trustworthy.

Use Cosign's verification guidance to define the expected signer and artifact. Protect signing permissions and avoid allowing an untrusted build to sign arbitrary output with a privileged production identity.

An SBOM attachment and a verified signed attestation are not interchangeable.

Admission policy needs a real verifier

The repository's signature policy contains a placeholder publicKeys value of kms://. It also limits matching to ECR images and excludes several namespaces.

That source cannot be treated as proof that every image entering a cluster is verified. Configure an actual supported trust source and validate the policy against the deployed Kyverno image-verification behavior.

Test a valid image, an unsigned image, an unexpected signer, an excluded namespace and an unavailable verification dependency. Confirm enforcement from observed admission results.

Keep detection and response distinct

Secret scanning can miss a credential; a local hook can be bypassed. Runtime detection can report suspicious activity, but an alert alone does not isolate a workload or revoke a session.

Any automated response needs its own implementation, permissions and false-positive handling. Kubernetes admission and audit events should not be described as automatically appearing in CloudTrail without verifying the actual logging path.

Treat compliance as an evidence assessment

SAMA's asset-management section is 3.3.3 and concerns an organizational asset-management process. It is not a prescription that installing Syft, Cosign or Falco establishes compliance.

A formal assessment must consider applicability, governance, procedures and operating evidence alongside technical controls. This article makes no certification claim.

Silsila provides a concrete starting architecture. Its next validation milestone is a reproducible build-to-admission test with real trust configuration and retained evidence of both accepted and rejected artifacts.

Sardar Mukhshaf

Sardar Mukhshaf

Full-Stack & DevOps Engineer

I build scalable web applications, secure backend systems, and production-ready cloud infrastructure. My engineering focus spans interface design, API architecture, deployment pipelines, and observability. Follow for more deep dives into system architecture, performance engineering, and emerging technologies.

More from the practice

Keep the useful ideas close.

Follow new articles with your preferred RSS reader.

Open the RSS feed ↗