Getting some traction on SAST testing
SAST or Static Application Security Testing or sometimes refer as Static Source Code Analyzer is a security mechanism in which source code vulnerabilities are detected early during the Software Development Life Cycle.
The truth of the matter is that writing secure code is damn hard, and manual code review is challenging even for the trained eye. It is good to see that the SAST landscape has evolved rapidly to adjust to the current needs of the DevSecOps principles.
I was introduced to SAST tools back in 2020 when I was working as a Software Engineer at Security Innovation in a project known as the TeamMentor platform, where we have created very comprehensive security guidelines and remediation efforts based on the underlying operating system.
The following year, Microsoft opened up the black box compiler in a set of APIs known as the Roslyn project and a new avenue for writing IDE plugins that essentially opened the door for better security and instant feedback to developers at the time of writing secure code.
Things have changed since then. DevSecOps initiatives and the advent of GitHub actions and CodeQL allow detecting security issues very early during the SDLC.
It’s great to see that SAST continues to generate lots of traction in social media and that we still have the same passion as we did back in 2012.
So it started with a tweet from Petra Vukmirovic
Which generated activity within the community:
I provided some feedback based on my understanding of Sengrep:
And Clint Gibler was kind enough to give an update on Semgrep and C#
Definitely, Semgrep seems to be a great tool worth to explore it, I’ll be writing about it in the next articles.
Lastly, I’m happy to see that passion around SAST still keeps its spark and people around the globe are striving to innovate and ultimately help the developer community to write more secure code.
