This talk will highlight the troubles of anyone who has owned or worked with a code base where the same type of security issue keeps presenting itself. The talk can also help those who are developing a new solution and want to conduct security by design and prevent security vulnerabilities.

Example: I will use an example of say an XXE vulnerability that keeps popping up in a .NET code base because of developers using XmlReader instead of XmlTextReader.

Variant Analysis: Instead of just fixing the identified vulnerability, I will talk about variant analysis and how your teams should treat any discovered vulnerability as an opportunity to learn and search across your entire code base. Learning objective here is tips and tricks on how to do variant analysis.

Understanding your problem: Do you have a single instance of this vulnerability as a problem, or 10,000 instances? How would you visualise this and explain the problem to your leader, management etc. What tools and technology can support this.

Building a secure module: Complexity is the enemy of security, so how can you make this functionality solved with a single module of code. If it’s XML Serialisation/Deserialisation then develop a single library to do this across all your products and solutions. Ensure this module does one job (and doesn’t have your business logic) that way it’s easier to justify white box code review of this module to management without concern in losing intellectual property.

Enforce it: Building code libraries isn’t a new concept, however enforcing them is the tricky thing. It’s easy to tell developers to use a library and not use the raw libraries of your language – but how do you know they are following your advice? As a developer I have a million things to consider, how can I be expected to remember every little thing. It’s a real pain to do variant analysis, identify 50 instances of an issue, work with your teams to resolve them all – and then find in 12 months later the issue is back. How do you solve this headache (especially if you have millions of lines of code) – Write your own code analysis.

Writing Code Analysis: Most languages have ways to conduct your own code analysis, at the very least grep can be your friend. In .NET you can write a Roslyn Analyzer which can be a very simple way to add code analysis to your code base. It might be too complex to write a code analysis rule that analyses every permutation of a raw language library you use e.g checking if your serializer configuration for your XmlTextReader is secure. So what do you do – use your secure module. With a code analysis rule we will blanket prevent every instance of XmlTextReader (and similar libraries – why not prevent all System.Xml usage) whether it’s secure or insecure and guide developers to use the module that does the serialisation/deserialisation with known, tested, hardened configuration.

But I have an edge case: Your secure module should work for 90% of use cases, but times will come where it won’t be sufficient and you will need to go back to the raw library or a variant of it. This is fine too, in most code analysis tools you can suppress and justify the reason for not following the rule. It is easier to identify and call out 3 places in code that need a manual code review, than having zero visibility on whether a library used in a million places is securely implemented.

Bug burndown: It is rarely as simple as writing a rule that breaks all builds if present. Teams have timelines and could have multiple production commits in a day, imagine if I couldn’t release until I fixed 100 variants of this single bug…it won’t work.It is important to start by putting bugs in warning mode first that will show developers the problem exists. It is important to then work with development teams to reduce that count to zero – and then make the rule and error (break build).

Eradication: Once that burndown hits zero and the code analysis tools aren’t identifying any more instances of your issue – you have eradicated your bug. Now that’s not stopping the bug from coming back, so let’s make that code analysis rule an error that breaks the build. Now it can never come back.

Additional Support: Most custom code analysis tools are supported by Static Code Analysis platforms such as SonarQube. Leverage this to extend your code analysis visibility of problems and build coverage across your products. This can help with providing visibility to management, understanding the burndown of an issue, and also providing training/awareness to teams on why this custom code rule is a thing.