Last week I was fortunate enough to attend AppSecEurope. There was much discussion about DevSecOps, the hottest trend today in AppSec. The talks were really inspiring and cover this topic from various vantage points. However, I would like to discuss two issues that are extremely relevant for the future of the industry and were missing from the discussion at the event.
Glue is a tool that coordinates various security tools. It makes the integration of various security tools with your CI/CD pipeline a lot easier. Glue already support various security tools like Checkmarx (SAST) and Snyk (dependency checker). You can find the full list of the supported tools here. Just by integrating a tool into glue, you can use all the existing reporters ― without writing custom reporter per tool. The other is also true – if you need TeamCity integration, just create a new reporter for Glue. Now all your tools will now also have TeamCity integration.
I think this is pretty cool, and it will be interesting to see this tool gain more popularity. Because of that, I was expecting to hear at least one talk at AppSecEurope about this tool and how it could improve the DevSecOps pipeline. It aims to become the security automation framework, and if it will success we all will benefit from it.
Threat modeling is a methodology to analyze a software design and look for security issues. OWASP has a great intro on the subject. This is an extremely important activity, and when done correctly can detect various security issues in the design. Such issues that might not be discovered by automated tools.
But the concept of DevSecOps and the “Shift Left” paradigm in general, is a challenge to threat modeling as it is done currently. These paradigms are a response to a change in the software world in the last few years. First, moving from a few, slow changes to a lot more faster changes. Second, moving from centralized ownership to decentralized ownership of deployment. Each of those is a challenge for a threat modeling. In a software that rapidly changed – how do you keep the threat model up to date? And when is the correct time to conduct a threat model?
Usually, the final design is unknown when starting to develop ― but you should take care not to delay it too much; the threat model might cover issues with your current design that require you to change it. The second change is even more challenging: in a decentralized world ― how do you make sure the threat model is conducted? There are no gates that will help you enforce it. These are all serious challenges to how we are doing threat model today. I was impressed by a few ideas at AppSecEurope on how to handle them. But, I do believe we have a lot more work in this area.
DevSecOps is a great step forward, and we at Soluto are already feeling a positive impact. I hope to hear more about these issues in the near future ― this is the main reason I wanted to share this information with you.
I am looking forward to hearing your feedback: what is your experience? How do you handle challenges like these? I’d love to read your comments below!