Empower Your Developers to Manage Application Security Vulnerabilities on their Own

It’s reassuring to see that everyone’s been taking security more seriously over the past several years. Both at a personal and at a corporate level (and everything in between), I see a lot more interest in users trying to avoid becoming potential victims of a security breach

I was tempted to say “cyber-attack” instead of “security breach”, but the reality is that a lot of times these are not complex attacks, or even attacks at all. Someone just forgets to cover something basic and an attacker or a curious individual exploits a weakness in the system. There have been several examples of people forgetting to change default credentials, allowing anonymous access into admin portals, not cleaning data coming from the outside, and the list goes on.

Rise of Application Security

There’s a big market for tools that enable companies to avoid these mistakes and catch them before they can cause any headaches. One of the areas that has seen a lot of increased focus lately is Application Security. Recent, high-level breaches that occurred with the likes of BA, Equifax and others have amplified this Security segment and brought it into keen focus.

Application Security poses an interesting challenge, though. Our end-game is helping developers to write better code and avoid releasing bugs in their code, which can prevent potential security breaches.

There are several approaches to this and they all have their merits. The old-school approach involved utilizing tools that security teams leveraged to find vulnerabilities, followed by sending listings of vulnerabilities to developers for remediation.

Empower Developers to Remediate Vulnerabilities

Recently, things have changed a bit and the more modern approach is to have automated tools perform this analysis on behalf of security and allow developers to receive the results and work on fixing things themselves. As simple as this sounds, setting this process up and educating developers which one of the hundreds of issues generated by the tool they should prioritize can be quite a challenge.

Anyone who’s rolled out an Application Security program to a development team will agree that it’s not an easy sell. Consequently, some organizations decided to go to the other end of the spectrum and try a different approach. If you don’t have issues in the first place, then there’s no need to use the tools, or when you use them there should be fewer findings to remediate.

Sanitize Your Inputs & Use Trusted Components

To avoid experiencing security issues in the first place, you have to educate people on best practices. With regard to application security, I would summarize this advice as follows: “Sanitize your inputs” and “Use trusted components.” Application security education sounds great, but here’s the challenge. All of that training occurs in a virtual (and occasionally in a real-world) classroom. If you’re anything like me, virtual learning is an appealing educational approach. But, unless we use the knowledge we acquire on a daily basis, it’s very easy to move on and forget.

While both approaches have their merits and come with different challenges, the best approach is my personal favorite:  learning by doing things. This is where we decided to use a concept that has been used in consumer-based technology for years. Everyone is familiar with spellcheckers and how they work, and everyone wants to avoid that curly red underline when they create written text. Similar to that approach, we created AppScan CodeSweep. CodeSweep is our first community edition of AppScan (free for everyone), which works in VS Code.

Ask Yourself: “Is My Code Really Dangerous?”

The purpose of CodeSweep is simple. It helps developers to find issues, tells them how to fix the issues and starts asking them the right questions whilst they write code, to make sure they avoid security issues in the first place. Our goal wasn’t to make a new security specialist tool, but to make a tool that intuitively trains you to ask yourself if your code is really dangerous and explains what elements of the code could make it so. The more you ask yourself this question, the more likely you are able to perform analysis in the future, without being prompted by a tool. Here’s a short demo.

 

The end-result of this is that you will learn good security practices without having to go for lengthy classroom-style lessons or wait to be pointed at by security when they find something in your code. As a developer, you don’t do anything different. No long reports from security, no training that breaks your workflow, you just write code and answer your own questions. We’ll be there to start showing you when to ask the right questions.

Learn More

Does this sound like a solid approach to you?  If you like to learn things by doing and want to learn more about security as a developer, have a go at CodeSweep.

You can get it here: hclsw.co/CodeSweep

We really like talking to our users or those interested in this topic so we encourage you to join our community: hclsw.co/CodeSweepCommunityInvite