CNCF published v2 to give
- The Organization’s a better understanding of Cloud Native Security (CNS)
- Provides factors to consider while implementing CNS
In this blog, I’ll share insight into the details.
Why do we need a different view with Cloud Native security?
- As workload can run anywhere (on-prem, cloud), traditional perimeter security is impractical.
- We need security focusing on the rapid business outcomes, which need rapid development and deployment.
- This requires security to move closer to dynamic workload and identify workload based on Attributes (Tags and Labels)
- Automation of security controls in application lifecycle and design by default architecture
- Introducing security early in the application lifecycle saves resources (Time and Money). For example, one misconfiguration in the development phase results in 100’s misconfigurations in the deployment phase.
- Software supply chain safety is essential to ensure protection from vulnerabilities and malware. This is a return map to rapid business outcomes.
- CNS can enable organizations to be more proactive than reactive. Let’s GET OFFENSIVE WITH SECURITY !!
Forethoughts on implementing CNS
Cloud Native stack composed of
- Foundation layer
- Application lifecycle
- Runtime environment
In the HOW section, we will see CNS implementation at various levels. Cloud Native applications can be deployed in various models IAAS, SAAS, PAAS, CAAS, and FAAS. So, we need to be aware how CNS varies with different deployment models.
Recommendation on How to implement CNS
CNS has to be injected through every phase of the application lifecycle
- Develop
- Distribute
- Deploy
- Runtime
Develop

- Artifacts (IaC, Application and Container manifest) are created in this phase.
- Scanning needs to be integrated with the IDE developer or in the pull request.
- Testing during the development phase should involve
- Threat modelling
- Deployment, Operating system, infrastructure and Database hardening
- Application testing (SAST, DAST, fuzzing, container configuration)
Distribute

- In this phase, Container images and VM images are created from the image definitions and specifications.
- Static application testing to identify bugs and faults in the software
- Scanning containers images for vulnerabilities and malware against threat vectors
- For confidentiality, Organization can encrypt software Artifacts
- Securing Build pipeline
- Isolate and restrict/limit projects on CI servers
- Enforce build policies
- Use of supply chain tool sign pipeline metadata so it can be validated in later stages.
- Harden the container images by evaluating
- Using Non-root user
- Limit access to resources
- kernel level restriction
- Container Application Manifest scanning/hardening
- Testing should have
- Application security scanning
- Application linting through
- Static application security testing considering
- vulnerabilities with the image provided in application manifest
- Using principle of least privilege (POLP)
- Identify security context and system calls
- Resource limit settings
- Dynamic application security testing
- Identify drift in IAM, configuration ensuring observability
- Static application security testing considering
- Security Artifacts and Images
- An organization should have different stages of registries in pipelines.
- Individual teams to have separate registries. Similarly, other registries for Production, Development and Staging.
- Only authorized developers can pull images to private registries from public registries.
- AuthN and AuthZ for the registries
- Signing, Trust and Integrity
- Digitally sign the below contents at build time and validate before use
- Container Image
- Configuration file
- Package signing
- Digitally sign the below contents at build time and validate before use
- Encrypting the container images.
This week we have gone through Why we need different views for CNS and recommendations to consider while implementing it in Application Lifecycle. In the next blog, we will see other phases in Application Lifecycle also see how we can identify and address risk along with compliance considerations.






Leave a comment