Since finding myself in a role where I’m the entirety of the product security team, I’ve been thinking about guiding principles, things like the agile manifesto, and all the awesome content I’ve seen from people like Tanya Janca (@SheHacksPurple basically everywhere) and other thought leaders in our space. I made this nice list of 10, which are in no particular order, and wanted to share them:
- Be transparent. Product security will always do our best to explain the reasoning behind decisions, new processes, and policies.
- Don’t be a blocker. We recognize that developers often have tight deadlines and conflicting priorities, and we will do our best not to slow down the pace at which software is delivered, while still raising the overall security of our products.
- Think like developers. Product security will try to understand the code, architecture, and design of our applications, and will aim to provide specific feedback instead of high level suggestions whenever possible.
- Make security accessible. We often are told how security needs to be everyone’s job, but it’s not always approachable or even made an option for some people to be involved. We want to have an open application security culture where everyone can participate, can receive communications in an understandable manner, and has the opportunity to receive security training if desired.
- Be pragmatic. We understand that not every single vulnerability always needs to be fixed immediately, and aspire to an approach of always making things a little bit better, rather than demanding everything be done at once. The team will provide clear priorities and work to come to a mutual understanding and agreement of how to best work together.
- Be data driven. We’ll collect data about what we do. Decisions made by the team will be backed by data when it’s available. When it’s not, we’ll do our best to start collecting it so better decisions can be made later.
- Be open to change. Outside of areas where we have legally binding inflexible security requirements, nothing is set in stone. If a process is not working, a decision was incorrect, a tool isn’t providing value, or we just want to try something new, we can change it!
- Value results over process. The end result of delivering secure software for our clients and business partners is more important than following a specific methodology. We prefer that teams find what works best for them to have good security conversations over following a process just to check a box.
- Assume positive intent. Good security starts with good relationships, which are built on respect and the assumption that we are all here to do our best work. Security gaps aren’t introduced out of malice, but rather out of process failures, lack of understanding, time constraints, or other reasons. We will never blame individuals.
- Keep things fun. We write software and do cybersecurity because we enjoy it and believe it shouldn’t be a chore. We should celebrate our successes, share awesome things we learn, and be relentlessly positive in our pursuit of securing the organization’s products.
I’m still learning a lot, so I know there’s room to improve here, and I try to be open to change! What do you think? What am I missing? Hit me up on Twitter (@Vidmaster) or Blue Sky (@vidmaster.bluesky.social) with your thoughts!