Principles for secure application development
You as a company want the software you’re developing to be secure. Of course. Here are some principles you should keep in mind for secure application development:
1. Don’t rely on a single point of failure
Ensure that you have resiliency, so that at least two things have to fail for something scary to potentially happen.
For instance, to exploit a dated, vulnerable dependency inside your container, your attacker first needs to get into your pod and then exploit the vulnerability. That’s two steps.
2. Utilize the platform
If you’re running on GCP, use Google Secret Manager. Use GitHub Actions Secrets for your GitHub Actions. And so on. If you have a platform team, enable them to use sensible defaults.
3. Look for the weakest link
A good rule of thumb is to look for the weakest link in your system. This applies to several levels — find the weakest link in your processes, in your overall security setting, and in your dependencies. In this post, we’ll focus on the latter, and although there isn’t a textbook answer to what your most exploitable dependency is, there are several questions you can ask:
- Who, and how many, maintain it?
- When was it last updated?
- Are we on the latest version? And if not, how much would it cost us to get there?
- How much do we use this dependency?
- If we were to switch this dependency to a competing one, how much work would that be?
When you’ve identified the weakest link, the time has come to determine what to do. Maybe you just need parts of it? For general-purpose libraries such as Apache Commons or Google Guava, many applications need — and use — just a small part. Maybe you can copy just the code you need into your own codebase, and skip the rest of the library?
On a team I was at where we relied on a dated and abandoned library, I made the choice of doing some of the lifting myself. I’ve written the full story in this blog post, for you to enjoy and learn from.
4. Minimize what you have
The bigger the surface of your application is, the more things are there — the more ways to attack it.
This counts for your own code, so delete the code you have that you no longer need. That also makes it easier to navigate your codebase, and decreases the cognitive load. It also means that refactorings will be easier, as you don’t have to consider this code any longer.
Should you for some reason need the deleted code later, you can always retrieve it from the version control history.
It also applies to the code you are using that other people have created — what we developers call dependencies. Many problems and needs are the same across different systems, so it’s effective, smart and easy to rely on these existing libraries instead of coding everything from scratch yourself.
Examples of common use cases are login, monitoring, error handling, user sessions, feature toggling and so on. Keep those you use and need, but get rid of what you no longer need.
It also applies to the operating system you are running in production. You don’t need a full-fledged Windows, Mac OS or Linux installation to serve your regular business application. There are small, tailored Linux versions made for the exact purpose, so use them instead.
5. Keep the bar high
You should have automated checks in place to look for common vulnerabilities in your code or dependencies. If you consistently handle those, every new issue will be easy to spot, whereas if you have twelve open issues, the new one might be drowning.
Of course, there are more principles and more topics to consider. Many more. Maybe I write a follow-up post one day, but nevertheless, if you follow these principles, you’re in a far better state than if you don’t.
Principles for secure application development was originally published in Compendium on Medium, where people are continuing the conversation by highlighting and responding to this story.