As the CTO and co-founder of a fast-growing startup myself, I understand this reluctance. Your reservations might include the following:
-
Application security is important, but we don’t have the resources for an experienced and dedicated security staffer right now.
-
It’s hard to get my developers to care about security.
-
The prospect of eliminating all security bugs seems daunting.
-
The demands of our customers take priority.
As someone who has tackled these hesitations firsthand, here are some thoughts and advice I can offer on each of these concerns.
1. We Lack the Resources for a Dedicated Security Staffer Right Now
Maybe like me, you are the head of an engineering team who has been tasked with managing your company’s security posture on top of developing new features and maintaining your infrastructure. And maybe you have some previous security experience, maybe you don’t. Either way, you don’t have a dedicated security individual, which means you and your engineering team are the acting security team.
With a possibly limited security background, where do you start? There are several resources out there to help you learn about application security including blogs, books, publications, videos, online security groups/channels, Meetups, OWASP, etc. that you can start with. And if you don’t have time to do too much research that’s okay as well. There are also many tools available for you to leverage specific security knowledge. Ranging from vulnerability scanners to third-party penetration testing technologies to security training courses. In my experience, once you know what your most valuable assets are it’s beneficial to test a few things out and see what works for you. Each application is different and the only way you will be able to know what works best for your company is by exploring options and testing them out.
At Cobalt, we designed our pen testing platform to address the needs of companies that don’t necessarily have in-house security teams or processes and for companies that need regular external testing to keep them on their toes. A benefit of outsourcing security testing is that you can leave the testing up to a third party like Cobalt.
2. It’s Hard to Get My Developers to Care About Security
Often times, there can be a level of defensiveness when it comes to developers receiving feedback from security tests. They have put a lot of work into the code they’ve built, and for someone to come and tell them that it is vulnerable can be a difficult subject. It’s like when your product lead lets a developer know they built the wrong thing, just when that developer have worked day and night overcoming technical challenges. To get your developers start caring about security, you need to first educate them, then motivate them, and finally show that you value the creation of secure code. It is important to foster these insights and motives early on and offer positive reinforcements.
With a bit of training, development teams can learn to triage security test results themselves, as well as make good choices on risk and decision making. It doesn’t take too long to educate a team on some of the basics for managing security issues and have developers ask questions like these:
-
Is this issue actually a valid security bug, or is it just a “false-positive”?
-
How common are the circumstances that would generate the bug?
-
How severe are the consequences if this bug occurred “in the wild”?
-
How sensitive is the data that could be compromised due to this bug, what’s the impact?
A high risk of severely compromised sensitive data should obviously be a top priority. But it may not make sense to devote immediate time and resources to address small risk that might affect fairly innocuous data under highly unusual circumstances.
Development teams can be trained to assess the potential risk posed by a specific security issue, as well as the difficulty of addressing that issue. One way to inject a healthy respect for application security into your software engineering team is to have the developer responsible for the code in question assess the feasibility of fixing it and discuss the impact with other another developer or manager. The developer will be in the best position to know whether the security issues can be solved by just changing a line or two of code, or if resolving the vulnerability would require extensive revisions.
It’s important for your entire team to have a general understanding of a few basic security concepts — especially when it comes to recognizing risk. It’s also a very good idea for your developers to understand the security model and pitfalls of the framework — Ruby on Rails, for example — they’re working in so they better know how to code securely and what to look for in code reviews.
As previously mentioned, there are many resources out there for helping teach individuals about application security, casually educating the team by sharing articles, videos, and blogs can be a light touch to keeping security top of mind. What is equally as important to the education aspect of security is motivating your team to use their training and what they have learned to actually be more secure. Hosting hackathons, assigning points for secure code, and using group dynamics — such as sharing security bugs with the team and offering feedback on how to get them fixed, helps to build a positive culture. And celebrating fixes over bugs offers a great way to motivate developers around fixing bugs and avoiding them in the first place. Offering rewards and making security fun can reinforce developers to find and fix as well as not make the same insecure coding mistakes again.
3. It’s Impossible for Us to Address Every Potential Security Issue
As a startup this concern is common, security flaws are inevitable. However, only after you uncover security risk can you make a reasonable decision about how to respond. It’s better to know that there is risk and choose to hold off on fixing it than to be unaware and surprised later on. Triaging issues that are flagged in the penetration testing process is ultimately a judgment call, and you should be able to stand by your conviction.
One good thought experiment to help you decide whether you need to respond to a particular security issue that you’ve found is to ask yourself, “Knowing that security is about managing risk, can I objectively defend my decision as to why not to patch a security issue should it become a publicly known or I had to tell it to a customer?” Could you stand by the decision you made and why you made it? If not, then you should probably prioritize that vulnerability.
You might not be able to deal with every security bug you uncover — so start with the high-risk/low-cost-to-fix bugs. It’s also important to note that rather than fear the security risks you can’t see, celebrate the progress you’ve made in hardening your application security. Every fix is important and you should recognize that this will also help keeping your team motivated and inspired. Security is not an end-goal, but a process and a culture, so be sure to strengthen this process.
4. The Needs of Our Customers Have to Take Priority
One thing all of your customers want is some reassurance that you’re taking a responsible approach to security. If customers abandon your product because they think your software might expose them to a security risk, it’s not going to matter how many cool new features you have. You can lose trust in an instant, but gaining it back is no easy task. Customers will praise your features, but it all falls apart if they can’t rely on your service or trust it.
And here’s a nice little bonus: Many developers find that when they embrace a security-oriented mindset it prompts a shift in the way they code that makes their codebase more maintainable and simpler.
Concerns such as these four are what drove us founders to design a product like Cobalt’s application security solution. We wanted to create something that would address these kinds of concerns for SaaS startups and other companies that need a robust and cost-effective way to identify security issues — without adding new people or complex new processes into their software development lifecycle.
If you have questions about how you can incorporate application security measures into your software development lifecycle feel free to comment below or reach out to me via Twitter, LinkedIn, or email me at christian@cobalt.io.
If you are attending SaaStr Annual 2018 look for us at booth #93
