As summer winds down to a close, it’s back to school time for young developers who are looking to learn the skills that they’ll need for entering an increasingly competitive job market.
Employers are looking for developers who are not only creative, innovative, and efficient but know how to keep their code secure as well. Developers are taking on more responsibility for vulnerability management and security, raising the importance of learning good Application Security practices from the beginning of their career.
In hopes of helping student developers start off on the right foot, we have pulled together five points and practices to consider studying in the year ahead.
As developers, our first thought is how do I make my code work. While functionality is, of course, important, it’s not secure up to our standards, then it should not go out the door to customers.
We need to adopt a mindset of being aware of the security risks to our product, thinking about how we manage our vulnerabilities, and generally try to take a secure by design approach. This means following AppSec best practices, but also understanding that security is a part of the software development process that should be embraced.
Even if it may feel frustrating at times to deal with testing, it is far better to catch security issues at the earlier stages of development while they are still easy to fix. This is because we can often build out our code on top of a vulnerable component which will later have to be torn out and replaced, leading us to have to rework our product.
If we build on the idea that security shouldn’t be an afterthought, then one of our most important principles should be to test early and often.
You are probably familiar by now with the move towards DevOps methodology that runs a constant set of feedback loops to help make testing easier and faster, relying heavily on automated tools in order to improve efficiency. In DevSecOps, we have improved on DevOps by inserting security in the middle, quite literally in fact.
DevSecOps embraces the same desire for speed, and includes security checks to make sure that our code is coming out as free of vulnerabilities as possible. We use automated tools such as Static Application Security Testing (SAST) for our proprietary code, and Software Composition Analysis (SCA) for our open source components to help us identify potential vulnerabilities.
By shifting as many of our security checks to the earlier stages of development (aka shifting left) we can avoid incorporating vulnerabilities into our product. Using automated tools will help take much of the heavy lifting off our plates, allowing us to focus on other complicated issues that demand our attention.
There are few things as embarrassing as reading a press release about a breach and discovering that the hacked company had been storing sensitive customer data in plain text. This insult to injury should serve as a lesson to us about the importance of encryption.
While we always try to design our applications as secure as possible, nothing is ever 100% hack-proof. I suggest not tempting fate by ever claiming to be. This requires us to take measures and strategies like security at depth so that we can safeguard our data even if an attacker makes it past our perimeter.
Encryption using standards like RSA, Triple DES, and a few others that offer us some solid options for keeping our data secure even if it falls into enemy hands. These algorithms turn your data into an unreadable series of characters that can only become comprehendible with the right key, making them a fairly secure protocol to use.
The standard bit of advice that comes along with any description of encryption is not to roll your own. Doing encryption right is really, really hard for most state-level actors, so chances are that you’re not about to come up with an uncrackable version in your dorm room. This is one of those tasks that it’s best to farm out to a trusted third party.
Another option is hashing wherein your data, think passwords and the like, get stored in a string of numbers to obfuscate them. SHA-256 is a commonly accepted standard while SHA-1 or MD5 are considered to be outdated.
Whoever said that being a developer was all about the creative design and glory? Sometimes the best defense is just making sure that you have your bases covered on the basics.
It is easy to forget that we need to be concerned not only with security issues regarding our own code but also with security vulnerabilities in the dependencies that we use to build our products in the first place.
When we go into GitHub, Maven Central, or another source of useful open source components, it can be hard to keep track of what we are using and where. It can feel like even more of a task to look out for when vulnerabilities are affecting those dependencies — which you’ve probably forgotten you had — and see if there are any updates available.
However, these updates are important because they quite commonly include fixes to security issues that could lead to your app being exploited. In cases where there is an acute and pressing security concern, a patch might be pushed out quickly to plug the hole, the easiest and most comprehensive method to address a set of vulnerabilities is to push out a new and more secure version.
We acknowledge that there is always the risk that a new version might not be totally backward compatible, and you might need to spend time ensuring that they don’t break the functionality of the app. But it is still far better to get into the habit of keeping your dependencies updated and not allowing them to become a backdoor into your application.
If our previous tips were more big picture and perhaps strategic, we thought that it is still important to include a more practical tip that can save you plenty of embarrassment should things take a turn for the worse.
Always take the time to do your input validation as a crucial step to protect against malware injections. We need to remember that our applications are the interface that we create with the outside world for interacting with our internal data and systems. If we don’t test that the gates are in good working order, then who will?
So why is this a big deal?
The fine folks over at OWASP describe input validation thusly:
The most common web application security weakness is the failure to properly validate input coming from the client or from the environment before using it. This weakness leads to almost all of the major vulnerabilities in web applications, such as cross site scripting, SQL injection, interpreter injection, locale/Unicode attacks, file system attacks, and buffer overflows.
In more basic terms, input validation checks to see that nothing unwanted like malware or even just an overload of data for a DDoS attack will be allowed through to cause us harm.
For a more comprehensive look at the risks involved with input validation issues and how to test, take a look at this quick guide from OWASP.
It should be stressed that these tips are just the start when it comes to thinking and practicing AppSec as a developer. However, when we think about security, we often see that most of the issues come not from state actor level hackers exploiting 0-days but from the low hanging fruit of basic mistakes.
Before we end, no back to school list would be complete without a little extra reading, but we promise that this is one that you’ll appreciate.
The good folks at OWASP have uploaded a very nice collection of cheatsheets to their GitHub account for the benefit of folks like you. Explore this free resource here, and be sure to keep following us throughout the year for more useful tips and tricks on how to use open source smarter and more securely.