In my previous blog I wrote on how AWS embeds security in their teams. Jorge Liauw Calo challenged me to tell me a bit more on my security vision. So why not do another blog post ;-).
Some background, I have been working with AWS since 2009. So most of my opinions are formed by the input from AWS. This is not a bad thing because in general AWS is doing a great job developing safe and secure services. At AWS re:Invent 2022 I also heard the following quote:
Trust but verify!
I think that sums up my personal take on security as well. I mixed the input from AWS with my own experience as a developer and topped it off with my consulting experience.
Getting blocked
Traditional security departments tent to oppose al sorts of rules and frameworks on the development teams. The problem with this approach is that there are more developers than security engineers. This means that the security engineers do not have the time to guide the developers. The end result is that your workload cannot go into production because security would block you. And to be fair, they have good reasons to do so!
It is in the interest of the developer to embed security in your requirements. Based on those requirements you make sure you incorporate the security aspect in your design. Afterwards you can build your solution still with security in mind. By doing this you are not only lowering the risk of being blocked by a security team. You are also preventing the need of fixing the security issues after the fact. The effort that is needed to fix certain security issues is higher when you already build your solution than during the requirement and design phase of that same solution.
You should not rely on the control mechanisms opposed by the security team. You need to think for your self. Your team knows what your solution is doing and therefor you are the perfect candidate to secure it. In general those security team controls will work but in specific cases they are not enough.
You can use a lock, but you need to use it correctly to have effect!
Dependencies
When developing your solutions you will have to deal with dependencies. These dependencies might have vulnerabilities in them. Often you see that a vulnerability becomes a hot topic and the urgency goes up. It becomes something that needs to be fixed NOW!
Having tools in place to detect and notify, will reduce problems in the future. This allows you to prioritize, plan and test the mitigation. Instead of rushing a fix and hoping nothing will break. When these things happen it's not only the time that you spend on the actual fix. You also need to mobilize your teams on the spot. This will pull them out of there current task wasting more and more time.
By enabling the developers to proactively update their dependencies. They will gain control over this process and they are less likely to get distracted by urgent required fixes. This is good for the team morale and the development velocity.
By showing developers what the added value is for them. It is more likely that they will start adopting these security principles. At the same time you will improve your security posture, and increase your development velocity!
Conclusion
When you also focus on security during the requirement and design phase, you will safe time in the future! This time can be used to develop new features improving your developing velocity while improving your security posture.
Top comments (0)