The 5 Myths of Application Security

I've been spending a lot of time across multiple organisations with many views of DevOps, Agile, and ways of working. The follow 5 AppSec fallacies are most common, starting with a personal favourite of mine;

5. It takes too much time

Mostly 2 things in AppSec come across as time consuming, but they originate from Operations and Quality roles and are not the reality of AppSec.

Yes vulnerability triage is time consuming and hard for Operations because the people do not usually have a background in application development who can easily follow execution paths to know if there are any vulnerable code usages, and because the operations staff usually do not maintain the code.

Beside let's face it, vulnerability tools in the operations space are terrible, they're full of false positives and typically security or operations just tell you to patch all findings even if they're not relevant or even an exploitable legitimate vulnerability. Worse, the Operations tools give you feedback many days or months after the vulnerability was introduced. So the context and nuance is lost and this is why it is really hard to triage.

AppSec tools raise vulnerabilities inside the developers IDE directly, or run on their development environment in normal build/test workflows.

I digress and I know this is controversial, but running tools in the CI / CD or pipeline tool is also not helpful to developers. It really only assists security or operations teams to gain some assurances.

Pipeline scanning is NOT \"shift left\", it's \"delegate left\"

Secure code development needs feedback before you spend 5 hours integrating an image processing library only to learn in the PR later there are vulnerable methods and an alternative method should have been used. Or worse, after a PR is approved the pipeline for production integration has a tool that checks for licensing incompatibilities, and you then need to go find a totally different library and start again.

Let's talk about DevOps; Imagine saying today in a planning meeting that \"DevOps\" takes too much time, so we will skip it for this project. That's simply no longer acceptable and anyone will tell you the initial effort to setup automation saves you in hundreds of ways.

AppSec is the exact same, in fact AppSec is still DevOps if you truly understand the DevOps principles.

Just add the tools to your IDE and fix the issues before you commit code

AppSec will actually save you infinite effort. Consider how much time the team will save too, how much time will be saved if the security team doesn't have 100s of thousands in vulnerabilities to manage, report on, and beg the leadership to fund them to help fix.

AppSec can save millions in funding teams

This cost saving is not just for the security team, it is savings for the entire technology team including those who are not in technical roles because they support the team through security issues. If only all of the development team members applied the initial effort to setup a security conscious development environment in the first place, to write code that isn't violating licenses, standards, or policies.

The result would be far less time consuming for themselves and everyone else. AppSec saves you time.

4. It's the security teams job

Is it also the security teams job to protect your bank account with strong passwords?

I get it, you think you're not a target.

Your guessable bank password is easy to remember and it is more important to have easy access to the money because no one will ever try to take YOUR money.

Until it happens to you, and eventually all those bots looking for anyone exposed will find you eventually, only then will you realise it is up to you to secure your own bank accounts.

Security in an organisation is exactly the same, Security is everyone's job! If 1 person is insecure, the whole business is exposed to that mistake. It is really that simple.

The security team is not there to do security for you, they are there trying to spot the security problems and fix them, and in more recent years this includes education so that fewer security failings occur to be found in the first place. The security team head count is typically 1 for every 100 staff in SME, and 1 in every 10,000 for enterprise. That 1 security person cannot do your job for you, and it is your job to do Security at work no matter what you think or what your boss tells you.

I bet you wouldn't deny Security being everyone's job to the CEO

(please go try tell your CEO it isn't your job, can I come watch?)

3. The tech leads will do It

This is becoming far more common, and I hear it from everyone BUT not from the tech leads themselves..

The tech lead of a team has the experience to be quite good at Security

This is because they are experienced and have been exposed to Security for a lot longer than others. Just because a lead has the skills doesn't mean you can avoid Security or rely on them to do the Security work for you. Similarly if you are a product owner, scrum master, manager of any description, stop expecting leads to be the Security expert. Lead developers or tech leads as they are commonly called are as responsible for Security as you are as a manager, perhaps less responsible than you when it comes to an incident. If you are a junior or a manager, ask for assistance from the lead to help you, not do it for you.

2. Needed after a product is done

This one seems to be more prevalent in environments that are expected to be more secure, go figure. I think it has something to do with insurance, so that in the event of an incident it is expected the financial impact will be minimal so there will be a risk conversation about \"should we do X security activity\" during product development and this typically results in that risk conversation ending in \"do it later because it has low impact\".

It is pretty insane to think your product that works perfectly for the business case is a successful product when you not only don't know how poor it's security is because you didn't look, but it also has no known quality (because quality controls expose security flaws and vice versa).

In startups (and small teams in larger organisation) it is much worse than even this example. These agile products are usually deployed after a successful proof-of-x round. They prove the concept or prove the technology then proceed to showcase the success and this is what is deployed into a production environment.

Later a pentest or incident will uncover the trivial security issues, and it always turns out to be a very expensive response effort in terms of disruption and cost for something an hour might have solved in sprint planning and implementation.

I know you will probably leave the company after this project

But consider; your name will get passed around. I've seen many people have to change professions or career once their reputation has been black marked after an agile project is later looked at by their peers and they believed agile devops meant they need to cut corners in security. This is fundamentally the opposite of devops, and they didn't care to learn the security merits of the 5 ideals.

Gene Kim

Go read Gene Kim's books, until then you don't have a clue about DevOps. Just do security in the product development, if you need more resources you have the skills and it is your reputation that relies on a successful project.

1. AppSec is hard, high barrier of entry

This is just bonkers

Developers need to remember complex syntax and programming paradigms. They need to memorise entire code bases and refactoring is a daily occurrence from large multi-file efforts to a few lines of code or functions to keep thing DRY.

Designers and Quality Assurance people need to think up many ways end users may interact with the product, this relies on very creative thinking and a lot of trial and error is demanded for even a basic outcome. Engineers must also apply this when writing unit tests, however a good code coverage tool can assist in lowering the cognitive burden.

This segue's nicely into AppSec tooling, most AppSec professionals do not come into their role with any programming experience so the tooling accommodates this by not being very onerous to use. An AppSec task usually involves a terminal command like command --help to see what the capabilities are, and then follow the instructions. The highest barrier to entry into AppSec for non-developers is triage; where the AppSec role is to identify false positives and determine exploitability which means they simply check for the known vulnerable code usages in the product and if there are any code paths that expose the product to attacks.

Conclusion

If you are a developer and can follow code paths in a product (you can or you wouldn't be employed long) then the AppSec \"high barrier to entry\" is just an excuse, we all know it and if you think you're fooling anyone it won't take long for them to catch on and you'll look foolish for avoiding your AppSec.