The best software security solutions to your security requirements and challenges are specific to your use case, self-service and don't impede development velocity. This will often include creating custom, safe versions of functionality or not allowing the use of certain library functions which we know are dangerous. However, making sure that this guidance is constantly followed can be problematic. Whilst standard automated tools such as bandit or pylint may help discover generic vulnerabilities such as insecure use of pickle or security errors/misconfigurations such insecure autoescape configuration, how can we verify that our custom solutions and guidance have been correctly implemented and more importantly, stay that way, without writing complicated custom rules for these tools? In this talk we will discuss examples of custom solutions like this but more importantly, we will demonstrate how to continuously verify that the code remain in a secure state with these solutions implemented, on an ongoing basis. We will demonstrate using simple rule syntax provided by the free, open-source, Semgrep tool.Some example scenarios we’ll discuss:- Verifying we are not using a disallowed function in a 3rd party library.- Checking for the presence of security sensitive decorators in all places with allowed exceptions, etc.- Looking for a function that is called in an unsafe way.You should leave with ideas for how you can have custom and specific security guidelines that match your situation and how you can use a simple rule syntax to verify them as well as solve other similar code analysis problems.