Is it Tuesday yet? A company analyzed the number of vulnerabilities released each day. It’s a lot. And that’s just what gets reported. As a startup building a new product, it can be scary to think about application vulnerabilities sneaking through your release pipeline, new exploits against a heavily relied upon third-party library, or a mis-config in the cloud infrastructure. This post is going to exclusively focus on the public-facing side of things.

Setting up an alias where anyone on the internet can reliably get in contact with you about a security problem is crucial. There is a huge ecosystem out there of security researchers and white hat hackers. And yes, there are a lot of people who have fun “thinking bad, but doing good”.

Having the security email alias is the easiest way to be contacted if someone comes across a security vulnerability or finds your company’s data somewhere it shouldn’t be. If you have a spare hour and a half, feel free to entertain yourself with a failed attempt to disclose a data breach.

Basics to get started? Create an email distribution list called “security” in your domain. Monitor it for incoming messages. There will likely be spam and people trying to scare you, but the benefits significantly outweigh the overhead, especially when there’s a real disclosure. The next section about having a vulnerability disclosure policy will help set the rules and expectations.

What’s next? Setup additional records like a security.txt file on your website and a security DNS TXT record. This will bring more exposure to the fact that your business is open to the idea of receiving disclosures from the public.

What does Kinde do We created our security@kinde.com very early on and have set up both the security TXT record in our DNS and security.txt file on our main website.

Once you have a means for people to communicate with your business about security vulnerabilities, you should set up the rules by which they engage with your business and what they can test, otherwise known as a vulnerability disclosure policy. This will guide both parties with information about what URLs to test, anything you don’t want to hear about (such as DoS testing), and the best way to get in contact with your team.

It also serves as an advertisement on your website that you’re open for testing as long as it doesn’t blow up production. This also gives you a place to offer rewards if that’s something you’re interested in. The rewards don’t have to be monetary either. It could be a public hall of fame, swag, or gift cards. But if you’re not offering rewards, make sure that this is clearly stated in the policy so that nobody is confused about your position. And just to be clear, you don’t need to offer rewards.

Basics to get started? Use the template from Disclose.io’s Policy Maker. This will give you a kickstart that can be customized to your heart’s content. If you want some inspiration, Disclose also runs a community-maintained list of vulnerability disclosure programs. Be sure to add yourself in there once it’s ready.

What’s next? Creating a bug bounty program would be the next logical step. You can either do this yourself by offering rewards or offload to a third party like BugCrowd or HackerOne to handle the communications and payments. Reasons for using a third party would be because of the time it takes to respond to the incoming submissions, triage them, pay out valid bounties, and the general overhead of maintaining it. Bug bounties also attract better submissions because the security researchers know that they’re making some money off of them.

What does Kinde do? We published a vulnerability disclosure policy based on the Disclose.io template to our website soon after setting up our security emailing alias and DNS TXT record. We don’t offer rewards, but who knows, maybe that will change in the future.

Scanning your website for vulnerabilities is critical to knowing if there’s a hole that could lead to a data breach. There are a lot of free tools available to perform these scans. Start with the most publicly facing endpoints that customers will be using and then work your way through everything else that came up while mapping your attack surface. External vulnerability scanners will help you find the low-hanging fruit that’s easy to detect and likely easy to exploit. If you find a vulnerability with one of these tools, then there’s a good chance that anyone on the public internet can also find that vulnerability.

Basics to get started? Start with a few of the well-known open-source scanners, such as OWASP Zap and Nikto. Both can be run using automation if you’re into that. Zap also has a fun feature where you can interactively browse through a website and it will scan each page that you land on, which is useful when you need to scan after authentication.

What’s next? License an automated commercial scanner. These will run scheduled scans and alert you of any findings. Most of them support automated authentication handling so that it can scan beyond a login on a dashboard page, however, the features will vary depending on the vendor. And depending on the industry you operate in, sometimes the output reports will be necessary for customers or compliance.

What does Kinde do? We started by using OWASP Zap on the earlier versions of the product but then ended up licensing Intruder to perform weekly scans of all our public-facing infrastructure. We still use OWASP Zap for manual testing of some post-authentication flows where it’s difficult to automate.