How does a SaaS startup CTO balance development speed and security?

Learnings from past SaaS companies

In a typical SaaS startup you’ll find the dev team under heavy pressure to deliver new features. You usually have competitors who might be better funded, you’ll have the sales team asking for one last feature to close the deal, the customer support team asking for a bugfix. It can be hard to prioritize security unless a bigger enterprise customer demands it or your board imposes it from the top.

In most startups, you might not have a full range of tech profiles at your disposal: you might not have a full-time product manager yet, you probably don’t have a full-time head of security on your development team. A dev team under pressure to deliver will be forced to cut a lot of corners, even when it comes to security.

I have been the CTO of 3 early-stage SaaS startups. (Teamleader, Officient & Futureproofed) Below I’ve outlined my learnings from those past SaaS company experiences.

Avoid reinventing the wheel

A great example: don’t build a login system with passwords. Yes, you could build it in a few days, but the cost to maintain it and add advanced protection features in the future will be very high. Consider using a login via Single-sign on such as Gmail or use a service such as Auth0.com.  You’ll not only have a smoother, more feature-rich login experience, but you also won’t have to worry about a whole class of login-related security aspects (brute-forcing, leaked user credentials in 3rd party services, avoiding and detecting account takeover attacks, validating email addresses, logging...).

In the end, if you pick the right vendor, you’re not just reducing your attack surface, you’re also winning time that can be spent on more valuable features.

Other great examples that could save you weeks or months are:

• Don’t store credit cards, use something like Stripe or Mollie or Chargebee
• Don’t run complex software like MySQL or PostgreSQL or ElasticSearch yourself. Use managed cloud services such as RDS.
• Don’t build your own logging systems. Use systems like Sentry or Papertrail (and don’t log any sensitive data there)
• Don’t run your own email (SMTP) servers, use a managed service like Sendgrid or Mailgun
• Don’t build websocket servers, use managed services such as Pusher.com
• Don’t build your own featureflagging system, use a service such as Launchdarkly
• Don’t build your own calendar integration, use a tool like cronofy.com
• When building integrations in general, check for Unified APIs in that space such as Apideck.

Invest some time in a crisis communication setup

Make sure you have tools set up such as a chat application to talk to your customers, or better, a managed status page or Twitter account where you can communicate problems. In case something bad happens it’s a great practice to enable the rest of your company to communicate to your customers while you focus on fixing the problem during a crisis.

Add global guardrails

You’re probably reviewing Pull Requests from your developers, great! It’s quite a task to review them for maintainability, performance, functionality. Do you have time to also review them for security? For sure you’ll be able to cover some risks, but it’s nice to be able to sideline some risks by adding some guardrails and global configuration.

Sometimes, you can get lucky and global fixes exist for specific issues.

• If you use nodeJS and don’t like thinking about prototype pollution, you should freeze the prototype to disable this class of attacks app-wide. Aikido can automatically build a Pull Request that does this for you.
• If you use SQL and are afraid of SQL injection attacks (you should be), you can use a WAF (like AWS WAF) or RASP (like Datadog’s app security) for app-wide protection
• If you’re discovering a lot of XSS attacks, you can likely remove a large part of them by introducing a very strict CSP policy in the browser.
• If you’re doing a lot of outbound requests based on customer input, you might be vulnerable to SSRF attacks. While it might be hard to block this completely, you might mitigate damages by making sure it can’t lead to something worse (such as an IMDSv1 attack on IAM credentials in AWS). Aikido monitors this in your AWS cloud by default.
• When dealing with object storage, avoiding specific types of functions such as Pickle, XML, (un)serialize in Java and PHP,.. and instead going for simple storage options such as JSON can avoid a lot of typical exploits related to unsafe unserialization. Aikido monitors for these kinds of functions in your codebase by default.
• If you use a CDN or caching mechanisms, use separate domains for your static assets with separate CDN configurations to avoid all kinds of cache poisoning attacks (ChatGPT ran into this trap recently)

Educate your developers with this one simple trick

There’s an easy hack (pun intended) you can implement in your processes. One quick question to ask the dev team during sprint planning:

How can the functionality we’re building get hacked? (& how can we prevent that from happening)

While the dev team may not anticipate every potential abuse scenario, this methodology is dead simple to scale. It’s a small extra step that encourages developers check in on security considerations before undertaking any development work.

Assign priorities to different parts of your codebase

Not everything will be as big of a target for hackers. Key components they love to target are :

• Payment systems, wallets, credit systems
• Functionality that connects to expensive APIs like SMS, voip (think Twilio)
• Password reset, login systems, user invites
• Export features such as PDF, Excel,.. exports that might perform risky operations
• Anything related to file, image uploads
• Features that do outbound requests by design, such as webhooks
• Any kind of feature that sends email, especially with personalized content

PS: Aikido can help you focus on only the top repositories in your startup’s universe by assigning risks levels to each codebase.

Don’t forget about the human aspect

As CTO in a small startup, you’re usually also the one in charge of operational security. Provide your team with the means to secure their accounts. Make sure they use hardware Yubikeys or software apps for 2FA and if possible, enforce it. Tools like Gmail allow enforcing this. It’s a great first line of defense against phishing attacks.

Staying up-to-date with security practices is hard

Learning about new kinds of attacks on software is hard. It’s hard enough to follow up on updates to the languages that you use (Python, Node, Go,..) or OS patching or popular exploits in open-source packages. Specific attack become more popular over time so it pays off to follow the trends. For example, after noticing an uptick in subdomain takeover attacks last year, Aikido introduced a subdomain takeover monitoring tool to prevent that risk and to automate the practice of monitoring these DNS records.

Automate away

At my previous companies, we would try to get to a next level of security by having a security person build a calendar with recurring security tasks. Do an access-review for all apps every quarter. Do a leaked-secrets scan on the code every couple of week, clean up the open source package CVEs every Friday, do a SAST scan every so often, verify the DNS records for subdomain takeovers every month,... The output of these tasks was hard to triage and make actionable for developers. Worse, when this person left the company it was hard for anyone else to pick up these tasks because they required a lot of specific knowledge.

This is where the idea of Aikido started growing. We needed a solution to automates all of the above, filter out the noise and get the tasks in front of your developers in Slack or Jira.

Start scanning your code & cloud with Aikido today. Sign up over here and start scanning for free.