AWS re:Inforce 2019: Build Security in CI/CD Pipelines for Effective Security Automation (SDD351-S)

Realizing DevSecOps and effectively implementing security into CI/CD pipelines on AWS remains a challenging proposition for most organizations today. In this session, we share the essential principles of achieving security automation in your CI/CD pipelines and across the build, deploy, and run phases of your applications. Finally, we conclude with a demonstration of security automation across all three phases of your applications that are deployed on AWS infrastructure, showing you how to bring security automation to your organization.

Complete Title: AWS re:Inforce 2019: Build Security into CI/CD Pipelines for Effective Security Automation on AWS (SDD351-S)

Presenter(s):
- Ram Boreda, Palo Alto Networks
- Kevin Paige, Flexport

[georgesmith]

Actually the title is OK if you read till the end - "for Effective Security Automation". This plainly says "Outsource it to us by paying a subscription". I liked the playbook visualization in Demisto. Overall, no thumbs-up and no-thumbs down because I came for the first part of the title - build security in CI/CD pipelines and I did not see anything as to what kind of checks are performed under the covers. So, the moral of the story is: anything coming from an AWS Partner (APN) is a sales pitch, which is likely NOT what most people here cam to see.

[georgesmith]

If you want to minimize frictions for developers, don't ask them create Docker files. Have the DevOps guys build and secure the containers after the developers give them the dependencies. If they are not using the latest or most secure dependencies, then the build will fail and the developers will have to fix THE CODE, and NOT the Docker file. The core duties of developers ARE:
1. Build new features or enhance new ones - this is the most valuable part of their work for the customers
2. Fix bugs - also valuable but NOT as valuable as (1) because a minor problem with a feature still allows it to be used.

[georgesmith]

Overall the approach is wrong. Developers should not be building and securing containers, just application code. Their approach heavily puts the burden of maintaining Docker files on developers instead of automating the Docker file security completely. In this case, just upgrade curl behind the scenes updating the Dockerfile in the process. Also, say you had upgrade a version of a Spring JAR, then just upgrade it and if that breaks the code, the developers will be responsible for upgrading/fixing the code if the new version of the library affects the APIs in the JAR.

[John-shreds]

This was just a big advertisement. Right when you get to the meaty stuff, like drift protection; you just show some payed tool that solves everything. 🤦‍♂️