Win a copy of TensorFlow 2.0 in Action this week in the Artificial Intelligence and Machine Learning forum!

Julien Vehent

+ Follow
since Apr 23, 2018
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Julien Vehent

I think you can read Securing DevOps as a practical introduction to DevOps, but if you're interested in the topic and how to help your organization adopt these principles, I would certainly recommend reading books that are focused on this topic.
2 years ago
Securing DevOps is very suitable to software engineers. In fact, the target reader is a software engineer with some ops background and a few years on the job.
You don't need to have strong devops skills to go through the book, but a basic familiarity with operations and automation will certainly help. The rest, we'll explain
2 years ago
"DevOps" is a set of concepts, so one cannot "attack" it. But I think you're asking about common attacks against cloud services and CI/CD pipelines. Those are numerous, and range from account takeover (someone steals your github credentials) to infrastructure break-in. The most common ones are collected by the OWASP organization every few years, and published in their widely popular OWASP Top 10:
2 years ago
The book takes the reader through the building of a complete CI/CD pipeline that takes source code from GitHub, builds containers, and hosts those in an AWS ElasticBeanstalk environment in chapter 2. Then from chapter 3 to 6, we secure every layer of that pipeline, so, yes, we go through all the layers of DevOps, but we use a specific environment as example.
2 years ago
Yes, I believe it is useful for beginners. Our skills requirements are the following:

Readers should have intermediate skills in systems administration, and be comfortable with Linux and the hosting of websites. An understanding of Amazon Web Services and automation frameworks like Puppet and Chef, along with basic programming skills, is helpful, but not required.

I wrote Securing DevOps with the goal to train junior developers and operators looking into entering the security field, so I hope this will be a useful book to you, and I'd be very interested in your feedback if you think some areas should be further clarified.
2 years ago
Interesting topic! There is no clear answer here, it all depends on your tradeoffs (I discuss a number of options in chapter 6). You can save the container hash and verify it on the production server, which is OK but requires some custom scripts. The most secure solution is to use Docker Content Trust and enable signature verification on your production servers. That way, the system that builds docker images can sign them, and the servers that download and run those images can verify them. It's not an easy system to deploy, and you can shoot  yourself in the foot, but it does provide strong security guarantees.

The larger question that I think is worth asking is: "which third parties do you trust to handle your applications securely?". Many modern DevOps organizations rely heavily on third parties, like GitHub to host their code, TravisCI or CircleCI to test code and build containers, DockerHub to host those containers, AWS to manage the infrastructure, etc. Every time you engage a third party, you delegate a significant amount of trust to them, and this should be part of your security model. After all, there's little value in implement strong security guarantees on docker images if you allow an untrustworthy third party to build those images for you, or an untrustworthy third party to host and manipulate the source code of your applications.

Organizations that have very high security requirements end up hosting and building their entire pipelines in-house. In the case where you control all of the server components that host, build, ship and run your applications, does adding a signature truly increase security? Is the signing server somehow a lot more secure than the rest of your infrastructure? This gets philosophical very quickly, but you see where I'm going with this. It's all a matter of trade-offs and risk acceptance.

So, if you only want a basic security check, verify container hashes. If you want to solid secure solution, use Docker Content Trust. In both cases, first ask which 3rd parties you trust to modify your application, and design your controls accordingly.
2 years ago
"Monitoring and responding to attacks" is primarily about building a logging pipeline, you are correct.

However, AWS alone does not provide all the functionalities you want from a complex pipeline capable of detecting security issues. Cloudwatch Logs, for example, can play the role of a streaming and storage layer, but you will need a separate application to implement an analysis layer to continuously look inside those logs and raise alerts. In the book, we use Mozilla Hindsight, but there are many other tools that can do the same thing, and you could write your own serverless alerting framework using Lambda functions.
2 years ago
One of the most important concept of DevOps is the idea of Pipeline: a serie of steps that your application follows to go from being released by a developer to being deployed to test environments, verified, approved and finally deployed to production. The more efficient and reliable your pipeline is, the faster it becomes to release new versions of the application at fast pace while maintaining the assurance you're not breaking users or downgrading security.

There are several good tools for managing a pipeline. Jenkins is probably the most popular one, but there are others. What I would recommend is running your regression tests and security tests in your pipeline, after your application is deployed to a QA/staging/test environment, and before it is deployed to production.

For example, consider the pipeline below. It deploys a service called "TLS Observatory". The application is first deployed to a staging AWS account automatically, then a set of web security tests called "ZAP Baseline" are executed to verify that the staging environment still complies with the security policy. If all goes well, the tests come back green and the application is deployed to production.

2 years ago

 I think so many places don't think about the "responding to attacks" part of the equation very well.  

This is true, and working in a DevOps environment means using very different tools and techniques that one would use in a old-style infrastructure. (endpoint security on immutable servers? what about serverless forensics? etc.)

At the same time, a lot of proven techniques can and should be ported to modern environments, so the book goes over the important stuff and explains how to implement it.

There's also a little novel about a security incident in chapter 10. I had fun writing, I hope it's a good read
2 years ago
You can find the full table of content on, and the first chapter is downloadable there for free as well.
As you can see, we focus on a cloud service (a small invoicer API) hosted in AWS ElasticBeanstalk. But this is just an example we use to setup a lab environment and highlight the DevOps and Security concepts. I strongly believe that the book provides useful content to everyone, regardless of how your own environment is designed.

2 years ago
Securing DevOps is a technical book, so we talk about tools and techniques a lot! Part 1 is a complete implementation of a CI/CD pipeline and all the security components that we can fit into it. It's 100% hands on. Part 2 is also very technical but more focused on presenting tools and techniques and less on helping the reader implement them (you'll have to do homework). Part 3 is a little less focused on tool but we still present half a dozen of them in the chapter on security testing (ZAP, Scout2, bandit, gas, etc.).

So, yeah, we talk about tools a lot
2 years ago
In the first chapter of the book, I define DevOps as follows:

DevOps is the process of continuously improving software products through rapid release cycles, global automation of integration and delivery pipelines and close collaboration between teams. The goal of DevOps is to shorten the time and reduce the cost of transforming an idea into a product that customers use.

DevSecOps then is all about integrating security into DevOps processes rather than bolting them on top, and provide a safety net that allows the organization to innovate and become successful while protecting its customers. In the book, I call this "continuous security" and break it down into three areas (quoting chapter 1 below):

1. Test Driven Security (TDS). The first step of a security program is to define, implement and test security controls. TDS covers simple controls like the standard configuration of a Linux server, or the security headers web applications must implement. A great deal of security can be obtained by consistently implementing basic controls, and relentlessly testing those controls for accuracy. In good DevOps, manual testing should be the exception, not the rule. Security testing should be handled the same way all applications tests are handled in the CI and CD pipelines, automatically, and all the time.

2. Monitoring and responding to attacks. It is the fate of online services that they will get broken into eventually. When incidents happen, organizations will turn to their security teams for help, and a team must be prepared to react. The second phase of continuous security is to monitor and respond to threats, and protect the services and data the organization relies on, through techniques like fraud and intrusion detection, digital forensics and incident response, with the goal to increase the organization’s preparedness to an incident.

3. Assessing risks and maturing security. A successful security strategy cannot succeed when solely focused on technical issues. The third phase of continuous security is to go beyond the technology and look at the organization's security posture from high altitude, via risk management and security testing, both internal and external, to help organizations refocus their security efforts, and invest their resources more efficiently.

This is as close to a definition of DevSecOps as I can get. One thing that is critically important is that you can't really do DevSecOps in an organization that doesn't first do DevOps. If your organization isn't there yet, this is where your efforts should start.
2 years ago
Sorry, the book does not cover industry-specific standards. It's actually quite hard to do without turning it into a 2,000 pages book that's usable in various countries.

I would say though that the security concepts in the book are very often required by those standards, so applying these techniques will get you very close to compliance in many cases.
2 years ago
Hi Rafael,

Please pardon me for quoting another page, but I think this section of the book description directly answers your question:

Securing DevOps explores how the techniques of DevOps and Security should be applied together to make cloud services safer. This introductory book reviews state of the art practices used in securing web applications and their infrastructure, and teaches you techniques to integrate security directly into your product. You'll also learn the core concepts of DevOps, such as Continuous Integration, Continuous Delivery and Infrastructure as a Service. You'll build an example service - an invoice management API - as you learn how to implement both DevOps and Security concepts together. By the end of this book, you'll be ready to build security controls at all layers, monitor and respond to attacks on cloud services, and add security organization-wide through risk management and training.

2 years ago
I think the privacy, data management and compliance with regulation concerns are orthogonal to DevOps. For sure, having clean and well establish development and operational practices helps with compliance, but you could be full DevOps, do hundreds of deployments a day in a fully automated pipeline with immutable systems and inline security testing, and still be incapable to deal with GDPR.

Regulation and compliance are really the realm of Legal teams. These teams translate laws and regulations into technical requirements, and engineers must be able to implement these requirements. Following DevOps principles facilitates implementation, but does not inherently bring compliance.

In this sense, Securing DevOps does not address data issues directly. It does, however, explain to the reader how to take proven security concepts, indeed created in traditional environments a long time ago, and implement them in modern DevOps environments. A firewall remains a firewall regardless of how the infrastructure is managed, but DevOps tremendously facilitates their management and increases their efficiency. This is what the book is about.

As for a volume II on Data Security, I think this is a good idea, and definitely an area where many engineering teams have unanswered questions.
2 years ago