It’s not enough to say you are good. The moment of truth is when an outside expert or peer takes a hard look at what you do – and then gives you an educated thumbs up.
In academia, this is a peer review and it is essential for any worthwhile paper. For software developers, it is called an external code review. This is just what we have done with our Scout browser. We’ve amassed enough changes (on top of Chromium code) to justify an external code review.
And before going into this event, it’s a good time to talk about our own internal “best practices” that we follow at Avira when it comes to coding. After all, an outside review can’t be better than the preceding coding that he (or she) is looking at:
Secure programming principles
This is a list of “dos” and “don’ts” we stick to when programming. It is an internal document that covers typical conditions. There are general guidelines (sprintf vs snprintf) and project specific ones.
For the Scout team, a major guideline is “Do not break the sandbox.” For Chrom(ium) browsers, the sandbox is a wall around the browser that separates it from the operating system. Even if the browser is hacked and turns malicious, it can’t harm the system. We make sure we don’t mess with that.
Code review during programming
We’ve configured our tools in a way that “only code that has been reviewed and accepted by two other developers can be pushed into the repository”. This is an important safety net for us as developers. Even when we have a bad-hair day, there are still two other team members that will check our code and make sure that we are finding the most efficient and secure ways to achieve our goals. We sleep much better this way as developers – and, even though they might not know it – so do end users.
Honestly: Sometimes it is a bit hard to accept this criticism, but as we do, we learn and improve.
We work with several external companies specialized in code reviews. They are experts at finding bugs and vulnerabilities in code. Whenever we have enough new code aggregated, we randomly draw one of their business cards out of our lottery and invite them to do an in-house review. This last time it was X41. They spent a week with our Scout team, checking our code and asking tricky questions. At the end of this time, they’d found a dozen bugs (minor to medium sized) for us to fix. It was an educational and fun week for the Scout developer team.
Fuzzing is a technology to bombard interfaces (network, files, user input) with unexpected data and then see what happens – a software crash or odd behavior. This can result from files that are slightly wrong, broken network packets, and much more. Thousands of these broken files can be tested per second – getting us closer to fully automated bug detection. We do this ourselves and the external company we brought in has lots of experience in fuzzing browsers.
The Chromium source code itself is already very well fuzzed (Thanks, Google!). But, the technology we added to the Scout browser package was not. Consequently, we got to do that ourselves.
One last thing: Bug bounties
Avira is running bug bounties for many of its products. These are fun events for creative tech experts as they can find bugs in products and get paid for it. But, we do not do that for Scout (yet). Most of our code is Chromium code and Google has its own bug bounty for these bugs. Doing a Scout bug bounty right now would be a quite boring event and not a very lucrative one for the players. We will be back as soon as we have more bugs to find.