Read on Twitter
0. I was asked yesterday how an org could protect SCM/build env against attack in an assumed breach scenario. Not perfect or exhaustive advice, but here are things I've done IRL.
1. Institute strong internal controls over code review and approval. Let devs know that peer review is not this:
2. Implement strong configuration management of your SCM and build environment. Config changes, new users etc. In gitlab, that means using the strong controls from #1 to monitor configuration changes to users, business logic, plugins, code certs and config file integrity.
3. Know and control your dependency environment. Maintain a local package repo, and version pin inside your manifest. Monitor for changes to hosted packages. Use a software composition analysis tool to measure package vulns.
4. Measure developer activity across your entire dependency chain. Note packages that don't have releases at 1/3/6/12 months. This is an early warning indicator of an AWOL maintainer who might hand control to unsavory characters.
5. Track your hash values and devise a way to link together artifacts at every point in build, integration, config, etc. The end goal being the ability to link artifact hashes from every step in the process so you can link built code all the way back to the release SHA.
6. MFA everything you can, vault every secret you can't. Use logging to identify secret use that doesn't correlate to a CI/CD job. Don't reuse secrets between projects.
7. Make sure you have strong access controls over your code signing cert provider, and vault the code signing cert. Build strong checking into code signing jobs to only sign code that passes your build approval workflows.
8a. I can't think of other things right now, which is why this last advice is most important. Threat model your whole process. Start with a high level stride from commit to deploy, and then zoom in on every single transaction over time.
8b. You're not going to be able to prevent every threat you find when you model it out well via STRIDE, but you likely will find more ways to monitor for weirdness.
That's it for now. If I missed anything, or have other gifs I like that need security advice, I'll update this.
That's it for now. If I missed anything, or have other gifs I like that need security advice, I'll update this.
9. I knew this would happen.
Front end devs: host all your remote code dependencies locally, don't make your users call them.
Use content security policy and subresource integrity on all of those assets.
Your page loads will be faster too.
Front end devs: host all your remote code dependencies locally, don't make your users call them.
Use content security policy and subresource integrity on all of those assets.
Your page loads will be faster too.
10. You will need an automated update process for packages that change a lot, that's fine. Build one that calcs the new hashes and updates the SRI accordingly. --BUT-- if a version on a file doesn't change yet the hash does, alert and inspect.
