Lucas - first as someone who has been in the IT weeds for a long time, I genuinely appreciate your attention to the security of code at the front end, and as a “newcomer” rather than treating it as an afterthought. You’re already ahead of many of your peers, and a bunch people senior to you as well.
While we’re obviously not writing Perl here, the Perl Best Practices book (O’Reilly) had a huge impact on my attitude and how I thought about the code I was writing. I think though, that was the point the author was trying to make. IMHO he wasn’t writing a Perl style guide, he wrote a how to think about what you’re doing guide. He also wrote a good bit about other people reading your code later. By writing code intentionally, with a structure and purpose, rather than haphazardly, I think we’re less likely to make sloppy mistakes that lead to security issues. It’s an old book by today’s standards, but you might find it helpful. I found it incredibly interesting from a psychology perspective.
Some writing more hardened code will come with experience. A multilayered security approach is often best - a combination of good code, good architecture (ie don’t put your internal databases facing the interwebs), appropriately configured firewall, and so on. Hardening at multiple layers reduces the risk of a bug in the code to be the one thing that gets you hacked.
Lastly, just a few general areas of code security to think about, some already mentioned:
- secrets should never be hardcoded. this hasn’t always been an option, but with tools like Hashicorp Vault, data bags, and maybe Chef’s own vault product (not sure haven’t used it) it’s much easier to avoid leaving your code full of things the world shouldn’t see.
- never trust user input. I find this doesn’t come up as much in Chef, but it does occasionally. If you’re taking input from a source you don’t own or control, think very hard about the right way to sanitize that input. Most languages will have built in mechanisms you can use to, for example, strip or escape HTML. Be insanely careful (or do everything to avoid) if you’re going to execute code or make a system call that contains any user input.
- use file checksums, especially if you’re pulling content - ie packages - from a third party, Chef has gotten better at making this a first-class property for built-in resources like remote_file. Take advantage of that.
- less Chef/code and more system related, but turn off services you’re not using and avoid starting up random services - or punching truck-sized holes in your firewall - without a good reason.
If something doesn’t look right to you, speak up. I know there can be that one person who gets angry if you ask questions like you’re challenging them or whatever, but I think most are happy (I am) to walk through their code with you and explain what’s happening, and why that thing you’re looking at isn’t a security issue, or - “oh man, good catch, Lucas. I didn’t see that. Want to help me fix it?”
