The document discusses the importance of integrating security into the software development lifecycle (SDLC) through a 'shift left' approach, emphasizing fast feedback loops and the necessity of explicit trust in development processes. Key strategies include implementing tools such as automated security testing and maintaining a software bill of materials (SBOM) to manage vulnerabilities. Furthermore, it highlights the need for auditable and verifiable security measures throughout the SDLC in order to establish a robust security posture against potential threats.

1. Shift left
Security
17.06.2022, Florian Kammermann

2. Agenda
2
1. The Fast Feedback Loop
2. Security in the Software Development Life Cycle (SDLC)
3. Trust in the Software Development Life Cycle (SDLC)
4. Securing Code and Configuration, Artifacts
5. Prevent of Attacks in the Software Development Life Cycle (SDLC)

3. 3
Fast Feedback Loop
SCM
(git)
Unit Testing Build
Test on
Env. X
Production
Coding
(IDE)
Instant
The more left we hold the sensor,
the faster we get the feedback,
the faster we fix it,
the lower the cost,
the lower the security exposure
sec - min < 5m < 7 min
< 30min
> 30min
Test on
Env. X
Test on
Env. X

4. 4
Fast Feedback Loop – The Business View
Cost per defect (functional, reliability, security)
Source: NIST

5. 5
Incident Types Impact / Probability
30x
25x
20x
15x
10x
5x
0x
Functional Reliability Security
30x
25x
20x
15x
10x
5x
0x
Security Reliability Functional
Business Impact
In case of a Major Incident
Probability of Occurrence
In case of Major Incident
Optimizing for Security is a difficult Business Case,
we have low probability with high impact.

6. 6
Security in the
Software Development Lifecycle (SDLC)
Traditional Security Measures
SCM
(git)
Unit Testing Build
Test on
Env. X
Production
Coding
(IDE) Test on
Env. X
Test on
Env. X
Optimized for Production
Traditional Security Measures
focus on Security Exposure in
Production

7. 7
Security in the Software Development
Lifecycle (SDLC)
SSDLC Security Measures
SCM
(git)
Unit Testing Build
Test on
Env. X
Production
Coding
(IDE) Test on
Env. X
Test on
Env. X
Focus on the whole SDLC
Digitalized Production assumes that every step has its security
posture

8. 8
The New Reality – Attack Vectors on the Software Development Lifecycle
NCSC
(Nationales Zentrum
für Cybersecurity)
OWASP Top 10
Executive Order
improving the Nations
Cybersecurity
− 04 Insecure Design
− 05 Security Misconfiguration
− 06 Vulnerable and outdated Components
− 08 Software and data integrity failures
Shift left Security
CISA Model part of Zero Trust Application Pillar
(CISA = Cybersecurity & Infrastructure Security Agency)
− Angesichts der zunehmenden Komplexität von Hard- und Software sowie der
fortschreitenden Digitalisierung der Gesellschaft stellen nicht zuletzt Software-
Abhängigkeiten eine grosse Herausforderung für die Sicherheit von Unternehmen dar.
− In den letzten Jahren hat die «US National Telecommunications and Information
Administration (NTIA)» mit Partnern an der Entwicklung einer «Software Bill of Materials
(SBOM)» gearbeitet.

9. 9
Security in the Software Development Lifecycle
How Security is applied to the SDLC
Traditional Security Measures (SAST, DAST / PEN Test)
Digitalized Production Security Measures (digital Identities and Bill of Materials)
SCM
(git)
Unit Testing Build
Test on
Env. X
Production
Coding
(IDE) Test on
Env. X
Test on
Env. X

10. 10
Trust
How we create Trust into the Software Development Lifecycle
Implicit Trust is created by ticketing systems,
by verbal communication by email or chat.
Implicit trust is not auditable and can not be
traced back programmatically. Implicit trust
is not verifiable. Implicit trust doesn’t protect
from tampering.
implicit explicit
Explicit Trust is auditable and verifiable by
digital evidence. Explicit trust also comes
with digitally represented parties, which took
an action in the SSDLC (Secure Software
Development Lifecycle). Explicit Trust creates
a chain of trust, which can be verified by
external parties.

11. 11
Accumulate explicit Trust over the Pipeline Stages
digitally signed propagation
Signed commit Signed SAST
Signed commit
Signed unit tests
Signed SAST
Signed commit
Signed build
Signed unit tests
Signed SAST
Signed commit
Signed x Tests
Signed build
Signed unit tests
Signed SAST
Signed commit
SCM
(git)
Unit Testing Build
Test on
Env. X
Production
Coding
(IDE) Test on
Env. X
Test on
Env. X

12. 12
Securing Code and Configuration
A foundation of securing
source code is the ability to
authenticate contributor-
added commits to the
repository. Unsigned or
unknown signatures have to
be rejected.
Commit Authenticity
Use SAST to scan the code
for vulnerabilities. SAST can
find code segments which
can lead to possible security
exposure.
https://cwe.mitre.org/
Identify malicious code
early
It’s still a problem, that
secrets can make it into the
code base. Use pre-commit
hooks to avoid sensitive
information in the central git
repository.
Avoid exposing sensitive
information
Review Code Changes by
qualified Coworkers. Create
short lived branches to bring
new code to main. Avoid
long lived feature branches.
Flawless Change
Management
x x
SCM
(git)
Unit
Testing
Build Test on
Env. X
Production
Coding
(IDE)
Test on
Env. X
Test on
Env. X

13. 13
Securing Artifacts before Deployment
Artifact Repositories play a central role
in the SDLC. The accumulated Trust
and Immutability needs to be
guaranteed by Artifact Repositories.
They are also the gate for incoming
artifacts from central repositories.
Artifact Repositories
Analyses artifacts to detect known
software components and identify any
associated vulnerabilities. Scanning
complements SAST by finding
vulnerabilities not detectable by
scanning source code and can also
help to build the SBOM.
Identify malicious dependencies early
VM images should be treated the
same as any artifact. They should go
through all the stages of the SSDLC.
For OCI Images, distroless images are
to favor, to remove all the non-
essential operating system
dependencies.
Managed base Images (VM/OCI)
Lib D
Lib I Lib J
SCM
(git)
Unit
Testing
Build Test on
Env. X
Production
Coding
(IDE)
Test on
Env. X
Test on
Env. X

14. 14
The Importance of the Software Bill of Materials (SBOM)
A “software bill of materials”
(SBOM) has emerged as a key
building block in software security
and software supply chain risk
management.
A SBOM is a nested inventory, a list
of ingredients that make up
software components.
Source https://www.cisa.gov/sbom
artifact
Lib A Lib B
Lib C Lib D Lib E Lib F
Lib I Lib J Lib K Lib L Lib M Lib N
Lib G Lib H

15. 15
Securing deployed Artifacts
Secure the deployment through the
validation of digital trust (signature).
Applying policies that require the
progressive series of signed
attestations protects environments
from accidental, or malicious, artifact
deployments. Open Policy Agent can
help here.
Apply Policies
Dynamic application security testing
(DAST) tests are designed to identify
functional security vulnerabilities in
deployed artifacts. Use DAST to
identify possible exploits following
known patterns of attack, like SQL
injection or cross-site scripting (XSS).
Dynamic Application Security Testing
Static environments are challenging.
To create environments where you can
test new functionality in isolation, use
Declarative infrastructure. These
environments are ephemeral. They
only live as long as the feature test
cycle is active.
Isolated and replicable testing
Environments
SCM
(git)
Unit
Testing
Build Test on
Env. X
Production
Coding
(IDE)
Test on
Env. X
Test on
Env. X
Lib I
stop

16. Infrastructure
Infrastructure
16
The importance of declarative Infrastructure (IaC)
Infrastructure – Ephemeral Environment X
Artifact
A key component of securing infrastructure is to use declarative infrastructure.
Declarative infrastructure is commonly known as infrastructure as code (IaC).
It defines infrastructure components as code, manages the components in code repositories, and
helps ensure that the infrastructure components undergo the same level of checks and balances as
application feature code. Declarative Infrastructure is the basis to manage ephemeral
Environments.
Artifact Artifact
Ephemeral Environment
Environments become
replicable. Environments (also
prod), can be created or rebuilt
automated on demand.

17. 17
Mitigation of Attacks
in the SSDLC
Malicious library Example

18. 18
Mitigation in a traditional SDLC
Lib Z Zero Day CVE
(manually) analyze Deployments
Maintain lists of Deployments to fix
Update every Deployment and build/deploy
Without an SBOM and trusted Libraries,
it can take days to weeks to rollout
Mitigations of zero-day CVE’s.
And even then, it is not clear all vulnerable
Deployments were discovered,
APT’s (Advanced Persistent Threat)
can take hold and lateral move.
SCM
(git)
Unit Testing Build
Test on
Env. X
Production
Coding
(IDE) Test on
Env. X
Test on
Env. X

19. Rotate datacenter credentials every
few minutes or hours.
Repair vulnerable operating
systems and application stacks
consistently within hours of patch
availability. Faster is safer.
Repave every server and
application in the datacenter every
few hours from a known good
state.
Source:
Pivotal, ThoughtWorks Techradar
19
Mitigation in a SSDLC with the 3 R’s of Enterprise Security
Repair
Version
Control
Unit Tests build
Verify on
environment
x
production
Requirements for Repair
• CVE tracking
• SBOM and (automated) manifest update
• Signed Artifacts
Artifact
Zero Day CVE
SBOM
SBOM
SBOM
SBOM

20. 20
Mitigation in a SSDLC with the 3 R’s of Enterprise Security
Rotate datacenter credentials every
few minutes or hours.
Repair vulnerable operating
systems and application stacks
consistently within hours of patch
availability. Faster is safer.
Repave every server and
application in the datacenter every
few hours from a known good
state.
Source:
Pivotal, ThoughtWorks Techradar
Version
Control
Unit Tests build
Verify on
environment
x
production
Infrastructure
Artifact Artifact Artifact
Requirements for Repave
• Declarative Infrastructure
• Cloud Native / Stateless Architecture
• Known trusted State
Repave
APT’s get starved
and can’t take a hold

21. 21
ISO 20’000 and SSDLC (Secure Software Development Life Cycle)
the international standard for IT service management
Automated and Auditable Software Supply Chain
The Software Supply Chain must be auditable to ensure ISO 20’000 compliance.
The Implementation of the Software supply chain has to guarantee that the Software supply
chain covers integrity and confidentiality.
Every step in the building, integration and testing process has to be secured that integrity and
confidentiality is guaranteed from the code commit to the running workload on production.
In a traditional environment this is/was mostly done trough documented human interaction
(handover, signoff etc.)
If we apply zero trust to the SDLC and combine it with an audit trail, this requirement is already
fulfilled.

22. 22
Shift left Security – Key Takeaways
Verifiable Identities
Its all about verifiable entities and trust
– zero trust applied to the SDLC results
in SSDLC
Standardizes Processes and Tools
Standardize Software Development
Processes and Tools enable SSDLC
Ephemeral Environments
Ephemeral Environments, immutable
artifacts and infrastructure is a must
Change the culture
Change the culture in your workforce
towards a security – zero trust culture
Enable the Developers
Make it easy for your Engineers to
deliver Software in a secure way

23. 23
Secure Software Development Lifecycle Journey
where is Swisscom
Threat Modelling
Threat modelling is
executed on critical
services / applications.
Actually this is the
“leftest” security
measure.
We have a security
program, which shifts
the security Know
How left to the
DevOps Teams. Every
Team should have a
certified Security
Champion.
App Sec Peaks
Snyk integrates
perfect in the Dev
Workflow to Scan
Code on
vulnerabilities and
sensitive information.
SAST/SBOM
with Snyk
Central repositories
are used to control
the flow from public
repositories and scan
inhouse produced
artifacts as also
external fetched
artifacts
Artifact repositories
Not pervasive, but is
used more and more.
The dominance of
kubernetes helps
here.
isolated ephemeral
Environments

24. References
• DevSecOps Booklet Swisscom
• Shifting Left on Security Google
• The Three R’s of Enterprise Security: Rotate, Repave, and Repair

25. 25
Question and Answer