Containers have become a standard deployment mechanism for modern .NET applications.
A typical application may move through several stages before reaching production:
Source Code
|
v
Build
|
v
Container Image
|
v
Container Registry
|
v
CI/CD Pipeline
|
v
Production
At every stage, there is an important question:
How can you prove that the container running in production is the same trusted artifact that was built by the expected publisher?
A container image digest can prove that a particular artifact has not changed since the digest was calculated. A digital signature adds another important property: it can associate that artifact with a trusted signing identity.
.NET 11 Preview 3 introduced signed official .NET container images. Microsoft announced that .NET container images are now signed, providing an additional supply-chain security signal for consumers of the official images.
This does not eliminate the need for dependency scanning, SBOMs, provenance, access controls, or runtime security. Instead, signing provides another layer in a broader software supply-chain security model.
What Does a Signed Container Image Mean?
A container image consists of metadata and filesystem layers identified by cryptographic digests.
A simplified representation is:
Container Image
|
+-- Manifest
|
+-- Configuration
|
+-- Layer 1
|
+-- Layer 2
|
+-- Layer 3
A signature binds the publisher's identity to the artifact descriptor, including its digest.
Conceptually:
Image Digest
|
v
Cryptographic Signature
|
v
Trusted Publisher Identity
When a consumer verifies the image, the verification process can establish:
The signature is cryptographically valid.
The signature corresponds to the artifact being consumed.
The signing identity is trusted according to the configured policy.
The artifact has not been modified since it was signed.
Microsoft's OCI artifact guidance describes signing as a way to establish both integrity and authenticity.
Why Container Signing Matters
Consider a normal container deployment:
Registry
|
v
Pull Image
|
v
Run Container
The registry may contain multiple tags:
myapp:latest
myapp:1.2
myapp:production
Tags are convenient, but they are mutable references.
A digest is more precise:
myapp@sha256:<digest>
Signing adds publisher identity to that immutable artifact reference.
The resulting trust model becomes:
Expected Publisher
|
v
Signed Artifact
|
v
Verified Digest
|
v
Deployment
This is significantly stronger than simply trusting a tag.
.NET 11 Official Container Images
Microsoft announced signed .NET container images as part of .NET 11 Preview 3.
Official .NET container images are available in different variants for runtime, ASP.NET Core, SDK, operating system, architecture, and other characteristics. Microsoft documents a tagging scheme based on the target framework, operating system, architecture, image type, and image variant.
A typical .NET application might use:
FROM mcr.microsoft.com/dotnet/aspnet:11.0 AS base
WORKDIR /app
EXPOSE 8080
and then:
FROM mcr.microsoft.com/dotnet/sdk:11.0 AS build
WORKDIR /src
COPY . .
RUN dotnet restore
RUN dotnet publish \
-c Release \
-o /app/publish \
--no-restore
The final stage can copy the published application into the runtime image:
FROM base AS final
WORKDIR /app
COPY --from=build /app/publish .
ENTRYPOINT ["dotnet", "MyApplication.dll"]
The signing of Microsoft's official image is useful when that image is used as a trusted base layer, but your resulting application image still needs its own supply-chain controls.
Signing the Base Image Is Not Enough
This distinction is important.
Suppose your Dockerfile contains:
FROM mcr.microsoft.com/dotnet/aspnet:11.0
The official base image may be signed.
Your application image is then built on top of it:
Microsoft Signed Base Image
|
v
Your Application Files
|
v
Your Container Image
The resulting application image is a different artifact.
Therefore, organizations should consider signing their own final images as part of their CI/CD pipeline.
The trust chain should look more like:
Trusted Base Image
|
v
Controlled Build
|
v
Application Image
|
v
Organization Signature
|
v
Registry
|
v
Deployment Verification
OCI Signatures and Notation
The Notary Project provides tooling for signing and verifying OCI artifacts.
Notation is the command-line tool used to perform these operations.
Microsoft's current Azure Container Registry documentation describes Notation as a tool for signing and verifying OCI artifacts, including container images.
The workflow is conceptually:
Build Image
|
v
Push Image
|
v
Sign Image
|
v
Push Signature
|
v
Verify Before Deployment
This separates image creation from artifact trust.
Sign an Image With Notation
Suppose an image has already been pushed to a registry:
myregistry.example.com/orders-api:1.0
Notation can sign the image:
notation sign \
myregistry.example.com/orders-api:1.0
The exact command depends on the configured signing key provider.
In a real organization, the signing key should not simply be stored as a plaintext file on a developer workstation.
Microsoft documents integrations with signing services such as Azure Key Vault and Azure Artifact Signing.
Why Key Management Matters
The security of a signed image depends heavily on the protection of the signing identity.
Consider:
Private Signing Key
|
v
Image Signature
|
v
Trusted Deployment
If an attacker obtains the signing credential, they may be able to produce artifacts that appear to originate from a trusted publisher.
Therefore:
Protect private signing keys.
Avoid storing long-lived keys in source repositories.
Restrict who can sign.
Audit signing operations.
Rotate credentials according to organizational policy.
Separate development and production signing identities.
Azure Artifact Signing provides an alternative to managing certificate lifecycle directly through Azure Key Vault and uses short-lived certificates with a managed signing experience.
Verify a Signed Image
Signing is useful only if consumers actually verify the signature.
Notation supports verification:
notation verify \
myregistry.example.com/orders-api@sha256:<digest>
Microsoft's documentation demonstrates verification using a trust policy and trust store.
The verification process can be represented as:
Image
|
v
Find Signature
|
v
Validate Signature
|
v
Validate Certificate / Identity
|
v
Evaluate Trust Policy
|
+---- Trusted ----> Continue
|
+---- Untrusted --> Block
This is where signing becomes an enforceable security control rather than simply metadata attached to an image.
Trust Policies Are Critical
A signature can be mathematically valid while still coming from an identity your organization does not trust.
For example:
Image
|
+-- Valid signature
|
+-- Signer = UnknownDeveloper
Cryptographically valid does not automatically mean authorized.
A trust policy defines which identities are trusted for specific registry scopes.
A simplified policy concept looks like:
{
"version": "1.0",
"trustPolicies": [
{
"name": "production-images",
"registryScopes": [
"myregistry.example.com/orders"
],
"signatureVerification": {
"level": "strict"
},
"trustedIdentities": [
"expected-publisher"
]
}
]
}
The exact trust-store and identity configuration depends on the signing system.
Microsoft's Notation examples use trust policies to associate registry scopes with trust stores and trusted identities.
Verify by Digest, Not Just by Tag
Consider:
orders-api:production
A tag can move from one image digest to another.
For stronger deployment controls, use a digest:
orders-api@sha256:abc123...
Then verify the signature against that exact artifact.
A useful deployment pipeline is:
Build
|
v
Push
|
v
Resolve Digest
|
v
Sign Digest
|
v
Verify Digest
|
v
Deploy Digest
This prevents the deployment stage from accidentally resolving a mutable tag to a different image.
Integrating Signing Into CI/CD
A practical pipeline can be structured as follows:
Source
|
v
Build
|
v
Unit Tests
|
v
Security Scans
|
v
Container Build
|
v
Push
|
v
Sign
|
v
Verify
|
v
Deploy
The signing operation should occur after the final image has been built and pushed.
The deployment stage should verify the signature rather than assuming that the previous pipeline step was successful.
This creates a second security boundary:
Build Pipeline
|
v
Signed Artifact
|
v
Deployment Policy
|
v
Production
Example Azure DevOps Workflow
Microsoft provides an Azure DevOps Notation task that can sign and verify OCI artifacts in an Azure Pipeline.
A conceptual pipeline might contain:
steps:
- script: |
docker build \
-t $(REGISTRY)/orders-api:$(Build.BuildId) \
.
displayName: Build container
- script: |
docker push \
$(REGISTRY)/orders-api:$(Build.BuildId)
displayName: Push container
- task: Notation@0
inputs:
command: 'sign'
artifactRefs: '$(IMAGE)'
displayName: Sign container
- task: Notation@0
inputs:
command: 'verify'
artifactRefs: '$(IMAGE)'
trustPolicy: '.pipeline/trustpolicy.json'
trustStore: '.pipeline/truststore/'
displayName: Verify container
The exact task configuration depends on the selected signing provider and pipeline environment.
Microsoft's documented Azure DevOps workflow builds and pushes the image, signs it, and then supports verification through a configured trust policy and trust store.
GitHub Actions
The same concept can be implemented in GitHub Actions.
Microsoft documents a workflow using Notation and Artifact Signing that builds an image, pushes it to Azure Container Registry, signs it, and stores the resulting signature in the registry.
A conceptual workflow is:
name: Build and Sign
on:
push:
jobs:
container:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build image
run: |
docker build \
-t ${{ env.IMAGE }}:${{ github.sha }} \
.
- name: Push image
run: |
docker push \
${{ env.IMAGE }}:${{ github.sha }}
- name: Sign image
run: |
notation sign ${{ env.IMAGE }}@${{ env.DIGEST }}
The authentication and signing-provider configuration should be implemented using the identity and secret-management mechanisms supported by the chosen platform.
Do not place private signing keys directly in the workflow source.
Verify at Deployment Time
One of the strongest patterns is to make signature verification a deployment requirement.
Consider Kubernetes:
Registry
|
v
Image Request
|
v
Signature Verification
|
+---- Valid ----> Deployment
|
+---- Invalid --> Rejected
Microsoft documents using Ratify with Azure Policy to verify container image signatures in Azure Kubernetes Service.
This moves verification from an advisory CI/CD step to an enforcement point closer to production.
The exact enforcement architecture depends on the Kubernetes environment and policy stack.
Build a Chain of Trust
A mature container supply chain should verify more than one property.
For example:
Source
|
v
Controlled Build
|
+-----------+-----------+
| |
v v
SBOM Provenance
| |
+-----------+-----------+
|
v
Container Image
|
v
Signature
|
v
Registry
|
v
Deployment Policy
Container signing provides authenticity and integrity for the artifact.
SBOMs provide visibility into components.
Build provenance can provide information about how an artifact was produced.
Vulnerability scanning identifies known security issues.
None of these mechanisms replaces the others.
Signing vs Hashing vs Scanning
| Control | Primary Purpose | Answers |
|---|---|---|
| Digest | Artifact integrity reference | Did this artifact change? |
| Signature | Integrity + publisher identity | Who signed this artifact? |
| Vulnerability scan | Known vulnerability detection | Does it contain known issues? |
| SBOM | Component visibility | What is inside it? |
| Provenance | Build traceability | How was it produced? |
| Runtime policy | Deployment enforcement | Is this artifact allowed to run? |
A secure supply chain generally combines several of these controls.
Common Mistakes
Signing Only the Base Image
A signed Microsoft base image does not automatically make your application image trusted.
Sign your final application artifact as well.
Signing Mutable Tags Without Tracking Digests
Always know which digest was actually signed.
Storing Signing Keys in Source Control
Private signing credentials should never be committed to a Git repository.
Verifying Signatures Only in CI
If deployment can bypass the verification stage, the security control may be bypassed.
Where practical, enforce verification at the deployment boundary.
Trusting Any Valid Signature
A valid signature from an untrusted identity should not automatically authorize deployment.
Trust policy matters.
Treating Signing as Vulnerability Scanning
A perfectly signed image can still contain a vulnerable dependency.
Signing establishes provenance-related trust properties; it does not prove that the software is vulnerability-free.
Troubleshooting Signature Verification
Verification Fails With an Unknown Signer
Check the configured trust store and trust policy.
The certificate may be valid but not trusted by the verifier.
The Image Was Rebuilt and Verification Fails
That can be expected.
A rebuilt image normally has a different digest and therefore needs its own signature.
The Tag Works but the Digest Does Not
Check whether the tag points to the same digest that was signed.
Avoid using mutable tags as the security identity of an artifact.
The Image Is Signed but Deployment Still Succeeds After Verification Is Removed
That is expected if verification is only a CI step.
Signing does not automatically enforce deployment policy.
Add an admission or deployment-time verification mechanism where appropriate.
Testing a Supply Chain
A useful security test suite should include both successful and failed scenarios.
Valid image
|
+-- Valid signature
+-- Trusted identity
+-- Expected registry
|
+----> Deploy
Tampered image
|
+-- Invalid signature
|
+----> Reject
Untrusted signer
|
+-- Valid cryptographic signature
+-- Wrong identity
|
+----> Reject
Unsigned image
|
+----> Reject
Wrong digest
|
+----> Reject
These tests demonstrate that the policy actually enforces the intended trust model.
Best Practices
Sign Immutable Artifacts
Prefer digest-based references for security-sensitive deployment.
Keep Signing Separate From Building
The identity that builds an artifact does not necessarily need unrestricted signing privileges.
Protect Signing Identities
Use a managed key or signing service where appropriate.
Verify Before Production
Do not rely solely on the registry to tell you that an artifact is trusted.
Enforce Verification
Make deployment fail when required signatures are missing or invalid.
Maintain a Trust Policy
Define exactly which publishers are trusted for which repositories.
Combine Controls
Use signing together with:
SBOMs
Vulnerability scanning
Provenance
Dependency controls
Access control
Runtime policies
Frequently Asked Questions
Are all .NET container images signed?
Microsoft announced signed .NET container images beginning with .NET 11 Preview 3. The exact image and version should still be verified against the official image and release documentation being consumed.
Does a signed image guarantee that it is secure?
No.
A signature provides authenticity and integrity information. It does not prove that the image contains no vulnerabilities or malicious application logic.
Can I sign my own .NET container image?
Yes.
OCI-compatible tooling such as Notation can sign container images, and Microsoft documents integrations with signing systems including Azure Key Vault and Artifact Signing.
Should I verify the image in CI/CD?
Yes.
CI/CD verification is useful, but production environments should also consider enforcing signature policies at deployment time.
Why use a digest if the image is signed?
The digest identifies the exact artifact.
A tag such as latest can point to different artifacts over time. A digest provides a stable reference to the specific image being verified.
Conclusion
Signed container images provide an important building block for modern software supply-chain security.
For .NET developers, the introduction of signatures for official .NET container images provides stronger trust information when consuming Microsoft-provided base images.
But a secure supply chain requires more than trusting the base image.
A stronger architecture is:
Official Trusted Base
|
v
Controlled Build
|
v
Application Image
|
v
SBOM + Security Checks
|
v
Organization Signature
|
v
Registry
|
v
Digest Verification
|
v
Deployment Policy
|
v
Production
The key principle is:
Build trust into the artifact lifecycle, then enforce that trust at deployment time.
Container signing answers an important question—whether an artifact is associated with a trusted publisher and has remained intact—but it should operate alongside vulnerability scanning, SBOMs, provenance, identity controls, and runtime policies.
For teams building .NET applications in containers, that combination turns a simple image-push workflow into a more verifiable software supply chain.
Join the conversation! Your thoughts help the community grow.