When delivering a service, we want to be swift, have short time to market, be secure and compliant.
CI/CD focus on tooling, DevOps focus on culture. Agile or Scrum are focused on organizing and managing the work to be done.
The main pillars
Security Tooling in a CI/CD Context
CI Dilemmas & How we approached it
Dilemma: Analysis & Design
Some Design decisions can have fundamental mismatch with general DT Group Security requirements
Proposed solution: Analysis & Design
- Discussions are open (in Slack channels or via Gitlab Issues) and accessible/transparent
- Since designs and architecture are part of the repository (documentation), adding or changing architectures/design goes through a review process. We expect senior engineers to be aware of Group Policies and raise discussions in case something is not properly done/designed.
Typical problems with code are (not limited to):
- Code Smells
- Dependencies (inherited vulnerabilities)
- Exception handling
Proposed solution: Code
- We use SonarQube to identify and report Security Issues
- Linting and use of tools to identify vulnerable libraries
- Expand/formalize existing Security Rules
- Create specific rules to match Group Policies
- Specially if the rules match policies such as usage ofdeprecated methods, functions or standards (e.g. crypto algorithms)
Dilemma: Unit Testing
Input validation is perhaps the lowest hanging fruit for security at this level – and that can be dealt with at unit test level. Encoding and escaping are also on the list.
Proposed solution: Unit Testing
- This is not centrally managed, every squad is responsible to develop their own unit tests related to security (e.g. input validation, etc.)
- Reference materials and snippets to raise awareness
- Highlight use of language specific, battle tested tools: coverage, pytest, go test,etc. (community effort)
Dilemma: Integration Test
Perhaps the most common problem here is security versus versioning and feature of dependencies. Teams should be aware that they are using third-party libraries and those libraries are safe to be used (don’t contain known vulnerabilities)
Proposed solution: Integration Test
- This is not centrally managed, every squad is responsible to develop their security test framework.
- Proposal: create a baseline framework with examples
STATUS: Currently not widespread in Pan-Net
CD Dilemmas & How we approached it
Dilemma: Binary Verification
Make sure binarries signature are verified or at least do an integrity check. Binary signing can be done in several ways and will depend on the tools available in the environment.
Proposed solution: Binary Verification
Make sure binaries are signed or at least do an integrity check STATUS: Currently not widespread in Pan-Net
Dilemma: Bin Packing
A binary is most often not alone in an environment. The environment usually contains runtime dependencies and other tooling or OS which could increase the attack surface.
Proposed solution: Bin Packing
- Make sure images have a static validation process against known vulnerabilities after built
- Whenever possible use distroless-like images
Dilemma: Shipping artifact
The most common artifact is image, specially docker images. They may be safe right after built, but later in time they can become vulnerable (because a vulnerability was discovered later).
Proposed solution: Shipping Artifact
Continuous Security on artifacts is a must: they must be periodically tested, scanned, and if vulnerabilities are found, projects/developers must be warned.
STATUS: No central solution ATM (PoC X-Ray via Jfrog being done)
When building infrastructure sometimes engineers will hard code values (access keys, ssh private keys) or not fulfill corporate policies (e.g. use encrypted S3 buckets).It may also be related to missing network control mechanisms (e.g. security groups).
Proposed solution: IaC
Compliance check on existing IaC code before pushing / applying (in-line pipeline) should match specified compliance norms.
STATUS: Not widespread in Pan-Net
Dilemma: Deployment (stage)
This environment is known to be “as close as possible to production environment”.
Proposed solution: Deployment (stage)
This is the ideal place for a full check up on some compliance requirements:
- Make sure this stage is properly parametrized and ready to be deployed into production (there should be zero
- difference between stage and production, apart from some names/strings)
- Are all password and sensitive information stored outside manifests in a secure storage (e.g. vault)?
- Are there any hard-coded secret somewhere?
- Offensive security and more intrusive security tests (like penetration testing)
Dilemma: Deploy (Prod)
This environment is considered “too important to play with” (both on data it holds as well as its stability / availability).
Proposed solution: Deploy (Prod)
Perform compliance and read-only tasks:
- Are all password and sensitive information stored outside manifests in a secure storage?
- Are there any hard-coded secret somewhere?
- Monitor critical security components (e.g. SSL certificates)