Hi all,
In today issue you could find as always latest news from a Cloud & DevOps and as well some more stuff…
Today we here about
What is a SLSA Framework and why we should care about?
Why DevOps should understand DR?
We meet again Casper a friendly ghost 👻
Cloud News
Disaster Recovery with AWS managed services, Part 1: Single Region
Disaster recovery with AWS managed services, Part 2: Multi-Region/backup and restore
Disaster Recovery Solutions with AWS-Managed Services, Part 3: Multi-Site Active/Passive
Disaster Recovery is an important thing when designing a solution architecture for many scenarios but I think that also DevOps Engineer should take some care about this area. AWS brings us multi-part series about DR in AWS infrastrcture. Worth reading 📚
Maybe not directly a DevOps topic but GCP partenship with Casper Labs brings another Blockchain solution to the cloud 🚀. As we know also in Blockchain you need to do some CI/CD stuff.
Service Level Objectives (SLOs). While simple to understand – intentionally! – SLOs are frequently challenging to define in practice. And even though the specifics of an SLO vary across industries and verticals, we have found there are a number of practices and strategies common amongst teams that have successfully implemented SLOs for their workloads.
GCP tries to explain & give us some examples how to implement SLO in our organizations. Worth reading 📚
As always we want to have a smaller and smaller and faster containers. 👆some Tips & Tricks how to achive this.
In today episode I also highly recommend DevSecCon YouTube channel.
Why you should care about SALSA?
Many of us use NPM, NuGet, or other types of packages in our projects. However, have you considered what would happen if one of them were compromised and malicious code was committed to the GIT repository?
Unfortunately, examples of these types of attacks have already occurred. For instance, the famous Apache Struts attack led to the Equifax data breach. For more information, please see the Equifax data breach FAQ or studies conducted by the USENIX Security Symposium.
Here came SLSA framework to rescue to mitigate such a problems in a future SDLC.
What is SLSA
SLSA (Signed Git Commits and Signed Source) is a framework for securing the software supply chain. It involves using signed Git commits and signed source code to ensure that the code being used in a project is authentic and has not been tampered with. SLSA is designed to complement other security measures in the software development process, such as code reviews and vulnerability scanning.
The rise of modern software development practices has led to complex supply chains that involve many third-party dependencies. This makes it difficult to ensure the integrity of the code being used in a project, and creates opportunities for attackers to inject malicious code into the supply chain. SLSA provides a way to mitigate these risks by ensuring that the code is authentic and has not been tampered with.
SLSA is a collaborative effort between industry leaders and open-source communities to establish a common standard for securing the software supply chain. It is based on the principles of transparency, accountability, and trust, and provides a way for organizations to verify the security of the code they use.
By implementing SLSA, organizations can have greater confidence in the security and integrity of the software they use. This can help reduce the risk of supply chain attacks and protect against other security threats. SLSA is an important step forward in securing the software supply chain, and is becoming increasingly important as the complexity of the supply chain continues to grow.
For more information on SLSA, you can check out this article: https://medium.com/gitguardian/supply-chain-security-what-is-slsa-part-i-2887d7d38ec1. It provides a detailed explanation of the principles behind SLSA, as well as practical examples of how it can be implemented in the software development process.
Below is an example how typical SDLC looks like and where are the possible places for attack
Wrap up
One of the key benefits of SLSA is that it provides a way to mitigate the risks associated with third-party dependencies. By using signed Git commits and signed source code, SLSA ensures that the code being used in a project is authentic and has not been tampered with. This creates a more secure software supply chain and reduces the risk of supply chain attacks.
Another benefit of SLSA is that it provides a common standard for securing the software supply chain. This makes it easier for organizations to verify the security of the code they use, and to ensure that it meets the necessary security and compliance requirements.
Overall, SLSA is an important step forward in securing the software supply chain, and is becoming increasingly important as the complexity of the supply chain continues to grow. It is a collaborative effort between industry leaders and open-source communities, and provides a way to establish a common standard for securing the software supply chain.
In future articles I will deep dive into SLSA and how to implement on example Azure DevOps project.
Reference
Supply Chain Security: What is SLSA? (Part I)
Securing our Software Supply Chains using the SLSA Framework