Skip to content
This repository has been archived by the owner on Feb 5, 2025. It is now read-only.

Container SDLC Best Practices #8

Open
jonmuk opened this issue May 28, 2019 · 5 comments
Open

Container SDLC Best Practices #8

jonmuk opened this issue May 28, 2019 · 5 comments

Comments

@jonmuk
Copy link
Contributor

jonmuk commented May 28, 2019

Best practices from end to end container SDLC to include image scanning, signing and deployment particularly in a hybrid environment covering both on prem and multiple cloud providers.

One participant highlighted significant Artefactory bloat, inability to efficiently scan.

@ap0phi5
Copy link

ap0phi5 commented May 30, 2019

I would be careful not to go defining our own SDLC best practise guide - it would be better to have pointers to some of the existing work in this space. There is a lot of great work going on in the container security space and I would recommend we don't overlap and try to reinvent the wheel! It would detract from creating a platform for the more unique challenges FS orgs have.

@ashishdesaifmr
Copy link

We are trying to solve this at our firm by making a simple policy statement which says that all docker images (esp in-house apps) will be rebuilt every 120 days of faster. It mirror our OS patching model which is 60 days

@ashishdesaifmr
Copy link

Signature verification is a broken model as its not available on all platforms (hello AWS-ECS)
Scanning is fine however if you have a code scanning system as well, then you have a de-confliction problem as if Tool-A (code level scanning) says all good and Tool-B (image scanner) says high-issue, which team will deal with it (code team, security team, or someone else)

Lowest common denominator we see is meta-data that comes with every image, ie "CreatingDate" and SHA256 hash. So we use those 2 artifacts, SHA hash to measure which artifact is store and running/cached where, and CreationDate as the object on which to report issues. Happy to share our slide deck on our approach (we talked about it in Boston CSA meeting)

@jonmuk
Copy link
Contributor Author

jonmuk commented Oct 22, 2019

Thanks Ashish. It would be great I’d you could share the deck, I see this issue more as a collation of material and pointers rather than bespoke material (no ap0phi5's point).

I’m more of a proponent for the signature based model but I admit I don’t have to deploy to all cloud providers. I find the additional signature a better way to validate the image has been approved for release and that the integrity of the image is valid as you do with the hash value.

I also like the in-toto based approach where you can attest the execution of SDLC processes then validate the attestations at point of deployment or execution in an admission controller. It’s a little complicated to setup but gives a good level of control.

Does anyone else have suggestions or advice to share? I’m collating other SDLC data from conferences and the web to reference.

@ashishdesaifmr
Copy link

Container_Lifecycle_CSA2019.pdf

One change we made internally is that we are going to block/archive images from repo after 240 days. So there is a grey area between day 120-240, however reporting will catch folks doing the wrong things

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants