With so much sensitive data going on through software applications, software products need to be robust enough to protect its users from malicious actors. VP of Engineering Ken Kantzer believes successful code audits combine the efforts of management, software engineers, and cybersecurity to create a safer web environment. In this episode, Ken shares with us how code audits are a way of judging the integrity of code and determining if it is built in a way that would secure its users’ data.
Edited transcription
Ken Kantzer is the vice president of engineering at FiscalNote, a tech company specializing in global policy and market intelligence software products. Oddly enough, Ken was promoted to his current position after serving in the company as head of security, a move Ken believes was possible thanks to his commitment to getting things done. His work habits come from his varied experience. Before joining FiscalNote, he recalls taking part in a variety of projects, “from being a founder at a startup, up to being the head of engineering at a medium, late-stage startup.”
Leading/leadership code audits
Ken recognizes that being in the position of managing teams, whether it is engineering or security teams, starts by understanding “the importance of clarity in setting a vision” for them. With a clearly defined strategy, teams can depend on leadership for guidance and have autonomy for working and making decisions.
However, Ken understands that autonomy does not imply keeping a distance from teams’ everyday work and challenges. In turn, he encourages connecting with them, even if it means involving in menial tasks. “If you suspect there might be a problem somewhere, start going to that team standup, see for yourself what’s happening in that standup, what’s happening with that team; it allows you to very quickly debug”, Ken says.
Ken observed this hands-on approach when leading security teams in penetration tests and code audits. Code audits are meant to find vulnerabilities in code that potential bad actors could use harmfully. Ken describes pentest and code audit approaches as a spectrum of two extremes:
- Black box testing: Finding vulnerabilities from the outside and without access to the system backend.
- White box testing: Finding vulnerabilities alongside developers and with access to the code and its infrastructure, as well as dev environments and documentation.
When it comes to code auditing, Ken prefers white-box testing. By evaluating the code, code audits guide the engineers responsible for writing security measures within the code. In this way, code audits can also have inferences in other aspects of the code and its architecture.
To start an audit, Ken has his security team meet the engineering teams to provide a product walkthrough. This helps his audit team to focus, while also helping them to “understand the business side and what the product is meant for and what are the major use cases of it.” It also helps security teams to know when they find something critical to the product’s functioning, and, likewise, if a vulnerability is not as important or impactful.
White box testing can also help to identify security issues within the organization or point out inadequacies. According to Ken, the tools developer teams provide, as in the case of setting up a test environment for the product demo, are “a great insight into people’s DevOps practices and how easily automatable their local setup was.”
Tips for security awareness
In Ken’s experience, teams that have grown too quickly should be aware of the security concerns a rushed onboarding process can produce. When new engineers are demanded to do something that has not been taught to them, they might ignore best practices established to prevent found vulnerabilities. For this very reason, Ken believes promoting security is as straightforward as asking onboarding developers to read the online documentation of the framework of your choosing: “A lot of frameworks have very well-defined patterns for how, for example, you would avoid Cross Site Scripting, or how you would avoid SQL injection; if you follow that pattern, you’ll be fine for the most part.”
Secondly, Ken recommends using static code analysis tools to scan code when you are about to commit or integrate them into your coding. Ken says that after implementing one of these tools it will surely send many alerts, many of them false positives. However, “even the practice of going through the list and marking things as false positives will build up security awareness on your team of what these things are even looking for.” After reviewing false positives, it is possible to have a baseline and integrate it into your CI/CD flow as if they were tests that will alert you if your build suffers from a security perspective.
Withal, in Ken’s view, security and writing secure software has improved in the last decade. Especially in the case of web application development and browser security. Far off from how the media portrays it, Ken believes that the industry possesses a considerable “understanding of how the security model of the browser works and certain classes of web application attacks.”
Behind these security improvements, says Ken, are application frameworks and web browsers. He finds that frameworks have “sanitized user input” by making it, for example, “much more difficult for a user to enter unescaped JavaScript into a user field and have that be reflected back in the browser as untrusted code that was executing.” Web browsers, for their part, have evolved to combat these vulnerabilities and reduced the ability of attackers to act. The adoption of tools such as the Content Security Policy header has allowed sites to restrict what resources the users can load on the page while also setting up a “white list of what domains and resources you allow on your page.”
On the other hand, Ken admits that security cannot be overly confident. Exploits like domain takeover attacks are proof of it. Still, Ken also believes new solutions will arise to scrutinize code. Open source projects, for example, can potentially gather more people to work on their code in comparison with closed source projects, in which code is only looked at by the company’s engineers and during audits.
The bottom line
Ken recommends those interested in the practical aspect of cybersecurity to start off by taking a look at HackerOne’s Bug Bounty programs. “The greatest part about starting here is that those companies, especially the bigger ones, will give you a treasure map where they’ll basically tell you, ‘here are all our endpoints for stuff’,” he specifies. On the other hand, for those keener to research before practicing, Ken’s advice is to read OWASP’s top 10 document. This site yearly lists in detail the most common web vulnerabilities. After familiarizing themselves with these vulnerabilities, says Ken, beginners would be more than ready to start with practical exercises.
You can read more about Ken’s ideas on software security and management in his blog.
