Let me tell you a story about the worries and sorrows of a modern day tech lead.
His desire to write beautiful, lean and secure code was always in opposition to the time pressure, deadlines and suddenly increasing customer requirements he faced. Also, his team and family began to bear the consequences of his frequent night shifts and the overtime that was involved.
You've guessed it! I am this Tech Lead.
There is No Time for Testing
At my previous company, we worked on a complex web application. And in addition to all the programming under pressure, our code also needed to be tested properly. And even though our entire development team knew that this will backfire on us, we simply didn’t have the time or resources for sufficient security testing. Our executives weren't of any help either, as they often had other priorities. As a Tech Lead, I was never able to live up to my own standards, which after a while made me kind of sick and embittered.
Our Executives Don’t Understand our Struggle
Like in many other software companies, we always worked under immense time pressure. This led us to operate under the premise “done is better than perfect”. If the code was barely working, this was already sufficient for us. Unfortunately, my other tasks, such as mentoring Junior Developers, often came up too short. But especially the security testing did not get the attention it needed.
Although we did what we could with our limited time and resources, it was not nearly enough to ensure the level of security I wanted to provide to our users. But the problem with more advanced testing methods was their limited predictability. It was a pain for me to argue how an additional test run would improve our security and how much time we would have to spend on those tests.
What Could Have Helped Me
1. More Time & More Automation
Finding bugs in your old code is super frustrating. If you postpone the security testing until the very last moments before a release, the bugs you'll find are often already several months old. And in the worst case, the developers who wrote the code already moved on to another project. To prevent this time-consuming fixing process, we would have needed more time in the early stages of the development process for profound code reviews. And we would have needed tools that allow us to continuously test our software throughout the entire CI/CD lifecycle.
2. A Triage System for Bugs
For most of the bugs we found, we filed a ticket until somebody would have time to fix them. If we could spare a moment, we would just choose bugs from the ticket pool and try to resolve them. Usually, we only fixed the easiest ones, to quickly work off the backlog. As a result, we often missed serious bugs that later popped up in production. What we would have needed, in this situation, is a kind of triage system that reliably sorts the bugs according to their relevance and urgency.
3. A More Accurate Bug Reporting
To better anticipate the scope of our projects, we would have needed a reliable bug reporting dashboard that showed us what kind of bugs we've found and how much code our tests covered so far. Not only my team would have benefited from this, but it would have also helped me to convince our executives, why it’s so important to give us more time for our security tests.
The Good News
When I recently started at Code Intelligence, I was surprised to find out that there are already great approaches that address exactly those issues. The company provides a platform for automated security testing, that would have solved many of my former problems. But now I actually build the tools that I would have loved to use in my previous job.
CI Fuzz Bug Reporting Dashboard .
Click here to download a CI Fuzz bug report as PDF
Rethinking Application Security With CI Fuzz
Of course, some problems don’t go away. We still have ambitious deadlines to meet, and our priorities and customer requirements change fast. However, by automating our security testing, we can now fix most of the bugs in an early stage of the development process. Our testing platform even helps us with triaging the bugs, and provides us with information about the current code coverage. This helps us to fix most critical vulnerabilities right away and to document the minor bugs and the code smell in the backlog.
But what I like the most about the CI Fuzz reporting dashboard, is that the results are displayed very visually in diagrams, and metrics that I can effortlessly share with the whole team and the executives (either within the VS Code extension, or as CSV/PDF). This helps us automate our reporting and saves me a lot of time for other tasks. Instead of constantly justifying myself in endless meetings, I just refresh the report, and everyone is able to read from the dashboards how much progress we've actually made since the last sprint.
