Note from the publisher: You have managed to find some of our old content and it may be outdated and/or incorrect. Try searching in our docs or on the blog for current information.

I spent the weekend volunteering at the annual BsidesSF security conference, which piggybacks on the larger RSA Conference this week in San Francisco. A couple of the best talks involved issues related directly to CircleCI users. Here’s a recap for those who didn’t attend.

“How Secure Are Your Docker Images?” by Manideep Konakandla

There was standing room only for “How Secure Are Your Docker Images?” by Manideep Konakandla, who is a security researcher and student at Carnegie Mellon University. And when I say standing room only, I mean there were so many people in the room that organizers actually stashed a dozen overflow people behind the speaker!

Key takeaways included:

  • Remember not to store secrets in your Dockerfile or else fall victim to what happened at Twitter’s Vine product, where secrets were checked in and discovered by unscrupulous users.
  • Always set up containers with a user. By default, containers allow root access, which provides virtually unlimited access escalation privileges. Here’s the Docker documentation about how to do that.
  • Tag your docker images by version number and not the term latest. If a security patch is loaded into a new version of a latest image, any machine pulling it down will likely use the cached (and vulnerable) image instead.
  • Download all packages using GPG.
  • Use Docker Content Trust, which allows client-side signing and verification of image tags, among other things. Konakandla looked alarmed when only one software developer out of 15 (using Docker) said they were using it.

“Five Keys to Building an Application Security Program in the Age of DevOps” by Tim Jarrett of Veracode was another useful talk.

Key takeaways included:

  • Automate Security: Depending on the type of application under development, focus on automating as much security testing as possible. This keeps trigger-happy developers happy by avoiding gating and manual penetration testing.
  • Fail Quickly: Set up systems of code coverage to ensure the ability to rapidly locate the author of insecure code once it is pushed. This avoids having to track down someone six months after the fact.
  • No False Alarms: Focus on small amounts of good security data so alerts aren’t ignored by developers eager to deploy.
  • Build Security Champions: Make developers love security so they’re part of the solution.
  • Keep Operational Visibility: Track all deployed code.
  • Microservices: Pushing small amounts of new changes is vastly easier to secure and track than changes to monolithic code bases.