Simplify it for them
Security is often perceived as complex and cumbersome which makes engineers unwilling to work on it. In order to get things done you need to simplify and carefully explain your requirements.
Strive to make it easier to build secure products because cheaper it is to add security, more likely it’ll get included into SDLC.
You need to take an ownership over the processes and simplify the frameworks, knowledge base and other resources so they are easy to consume and use.
Developers have their stuff to learn and they don’t want to waste time digging thru confusing documentation which doesn’t provide clear guidance on problem resolution. They’re looking for high quality resources, so you are expected to provide well described set of practical action items.
If you ask people to use some security product like 2FA or SSO integration, ensure it provides great user experience. No one wants to waste time on learning ugly UI, just because security folks require them to use it.
If you don’t keep it simple and your requests become irritating, you won’t be able to build long term culture, because people will create mind maps in which security == pain in the ass.
Encourage and teach instead of demanding and judging
Don’t fall into a trap of judging and assuming that your peers have sane base level of security awareness. I’ve met successful senior software engineers and managers who after two decades of work experience had very limited knowledge about security engineering.
Everyone comes from a different background and have worked on projects with different priorities, so the safest option is to assume that they haven’t had a chance to become security-savvy.
It makes a lot of sense to create low-mid level security trainings to equalize the level of security awareness — both general security and technical security(e.g. secure coding)
This will create a baseline thanks to which you can speed up discussions and save lots of time when you know that everyone is on the same page and you’re not required to provide simplistic explanations of technology basics.
Extensively explain security requirements and identified issues
Every time you file a bug report or request a product feature, elaborate as much as possible to make clear what your intent and business profits/risks are.
While writing technical details, consider using ELI5 approach, so there is no confusion along the way and no surprises when the code is shipped.
Describe what the problem is and provide real life solution i.e. configuration excerpt or a piece of code that can be copy/pasted to fix the bug.
Engineers are tired of cocky security rockstars who just drop a fancy vulnerability name and shout “Fix it, it’s simple!”, so please don’t add more to this bucket.
While taking such approach, make sure that people understand you’re using ELI5 because you want to make everything clear so they don’t need to waste their time on redundant research. Express that you want to share your knowledge so they can learn and to make it easy for next generations and juniors to understand what was the case.
It’s important to not hurt someone’s feelings and it can happen if one thinks that you’re using ELI5 to diminish his knowledge. May seem to be a small thing, but you don’t want to create toxic atmosphere so always over-communicate to avoid any misunderstandings.
Dawid Bałut 