This post was first published on aurainfosec.com, written by Sally Vernon and Nick Malcolm. It has been slightly modified to fit this blog.
Developers creating software and applications for today’s businesses have a wide range of things to consider – from responsive design and accessibility, through to security. Add in cost and time constraints, and it’s easy to see why sometimes security can be overlooked or outright ignored until the end of the project.
It can be hard to prioritise security when everything seems to be working fine and the business wants you to be delivering flash new features. But any organisation is vulnerable to a breach, large or small, public or private – and the risk is not just related to the work of malicious attackers either! We can inadvertently make mistakes which cause security incidents.
That’s why developers need to think about security early on, and throughout the project.
If you are leaving security till a security test at the end of a project, it’s often much harder to fix those vulnerabilities or flaws. In some cases, you may need to spend a significant amount of time rewriting code, which just adds more delays and unnecessary workloads.
One of the best ways for development teams to bring security into focus is to utilise a “Secure by Design” approach. This is where pragmatic security activites are included early and often.
Many developers are familiar with the OWASP Top 10 Risks, but OWASP also shares ten ways to proactively spot and avoid security issues. These are the foundational building blocks of a secure application design, and should be part of any project.
https://owasp.org/www-project-proactive-controls/
Repeat the mantra – “What are we building, what could go wrong, and what are we going to do about that?”
It sounds basic, but by getting into the habit of thinking through the security risks and building your software to avoid them, eventually it’ll be ingrained. You’ll be saving yourself, your team and your client from having to spend extra time and effort fixing security bugs or responding to incidents.
Automating security-specific tests will help prevent you and others from deploying vulnerable code, now or in the future. Remember not to just test the ‘positive cases’, where things are expected to work, but make sure that the ‘negative cases’ return the correct errors too.
20 August 2020