Book Image

Hands-On Security in DevOps

By : Tony Hsiang-Chih Hsu
Book Image

Hands-On Security in DevOps

By: Tony Hsiang-Chih Hsu

Overview of this book

DevOps has provided speed and quality benefits with continuous development and deployment methods, but it does not guarantee the security of an entire organization. Hands-On Security in DevOps shows you how to adopt DevOps techniques to continuously improve your organization’s security at every level, rather than just focusing on protecting your infrastructure. This guide combines DevOps and security to help you to protect cloud services, and teaches you how to use techniques to integrate security directly in your product. You will learn how to implement security at every layer, such as for the web application, cloud infrastructure, communication, and the delivery pipeline layers. With the help of practical examples, you’ll explore the core security aspects, such as blocking attacks, fraud detection, cloud forensics, and incident response. In the concluding chapters, you will cover topics on extending DevOps security, such as risk assessment, threat modeling, and continuous security. By the end of this book, you will be well-versed in implementing security in all layers of your organization and be confident in monitoring and blocking attacks throughout your cloud services.
Table of Contents (23 chapters)

Baking security into DevOps

We have discussed the culture aspect of how security fits into an organization. Let's now discuss the technical aspect. When it comes to fitting security into DevOps, we are mostly talking about integration with an existing Continuous Integration (CI) or Continuous Delivery (CD) framework. There are various kinds of CI/CD framework. We may focus on how to integrate security with Jenkins, since Jenkins is the hub of the whole CI/CD ecosystem, such as code and commit, build, scan and test, release, and deployment. One typical CI/CD process with security tools integration is shown in the following diagram. Please be aware that security requirements, threat modeling, secure design, and architecture design are not in the diagram, since the security practices of these activities normally tie with the team process, and not directly with a tool, such...