Or the Virtues of Static Code Analysis* - Ok, so there aren’t 7 crazy things that only 90’s kids would understand. And personal trainers don’t hate this guy… at least as far as I know. We’re just here to discuss the value of code scanners.
What are code scanners?
For our purposes, the terms code scanners, static program analysis, and static code analysis are essentially synonymous. It is the analysis performed on your programs without executing them. Conversely, the testing that requires execution of your code would fall under the category of dynamic code analysis and includes things like unit tests, integration tests, or fuzzing tests. Static code analysis focuses on finding patterns that could lead to dangerous situations, violations of style guidelines, or usage of unsafe libraries/APIs.
Who needs to care about code scanners?
Management. The obvious answers are development teams and devops teams, but that is uninteresting. Asking these teams to see the value in code scanners is like asking them to use code editors with syntax checking and auto-complete. Engineering leadership and Product Management need to care about this work, because properly setting up and maintaining a good CI/CD (Continuous Integration and Continuous Delivery) pipeline is real work that takes real time. Many development teams will see the value of this kind of analysis and go without because of time constraints; management can empower them to build a better process. To management, this better process quite simply means some problems are caught earlier and the product is better tested upon release.
More motivation: who is this aimed at?
A non-exhaustive list of the types of coders that need static code analysis in their CI/CD pipeline.
The rushed coder - Mr. or Ms. happy
This coder is frazzled and as soon as he/she sees green anywhere a git merge happens and the task is “done”. Code scanners will detect some of the problems the rushed coder might introduce, but to get at the real problem here, balance a few things off of his/her plate and have the conversation to slow down (and maybe take a vacation).
The boyscout / the Swiss Army knife - over-prepared for everything and in coding that means over-engineered
This one is simple. A lot of thought goes into this person’s code, too much. Sometimes it is frustrating to read, sometimes it contains needless abstraction or convoluted control flow; this can lead to tricky interactions that hide usually simple issues. Code scanners can sometimes unearth these early.
The mad scientist - loves new / shiny cutting edge tools regardless of his/her experience and regardless of the tool’s suitability
Sometimes we have to do ugly things to get new tools/frameworks working. Sometimes we should have a code scanner yell at us for those decisions.
The person with a hammer - the whole world is a nail
If the hammer is including 3rd party libraries, eventually you’ll get burned. An accidental (or possibly malicious) piece of code will be at risk of running in your product.
Limitations of code scanners
First let’s zoom into the universe of things you’ll be protected against with code scanners.
All currently known threats?
No, there are definitely some threats the public doesn’t know about.
All currently publicly known threats?
No, some of those threats would require access to a running system.
All currently publicly known threats detectable offline?
No, but we’re getting closer.
All currently publicly known threats detectable offline and detectable by the code scanner?
Still no, but almost.
All currently publicly known threats detectable offline and detectable by the code scanner and configured correctly by you?
Bingo
Think of all of the threats that would require deployments or runtime configuration to detect. Has debug logging been turned on in production? Are the API’s set up blacklist known bad IP’s? When component A is broken or missing, how will component B react? And think of all of the threats that would require special contextual knowledge of your product. What data is privileged? Access policies, deployment account access, and basic feature requirements will not be known by code scanners and thusly won’t be tested. And even if a certain issue could be found through static code analysis, not every tool has a huge knowledgebase.
Final thoughts
Code scanners help you enforce standards in your code. Style and safety guidelines lead to cleaner, easier to read and easier to debug code.
Automated tools can create a false sense of security. Understanding the limitations of code scanners makes it easy to avoid that pitfall. Your organization needs to remember:
- Security trainingSecurity training for engineering teams is still vital
- Code guidelines should be understood even if style guidelines are enforced by CI/CD
- Architecture reviews are important because many bugs or security issues come from miscommunication between how components should be designed
- An in depth discussion of onboarding new technologies/frameworks about the best practices with the new tech and risks
- Dynamic code analysis: sometimes you just have to hit it with a hammer while it is running
There isn't yet a world that your engineers can ignore the need to be security conscious and static code analysis alone won’t get us there, but it can fix some headaches before they happen.
Surprises (outside of the R&D process) are the enemy of a healthy/sane engineering team. And with a properly calibrated expectation about what static analysis can offer a team, using code scanners in their development process can reduce the number of surprises they encounter.
