Security is one of those arts, especially when it comes to the programming side of things, that one tiny chink in your armour is enough. There are people and tools out there which scan continually for the bugs and holes, either wearing a white hat and submitting them to bug bounty programs or similar, or wearing a darker shade of hat and doing much worse.
Of course, there are things out there which can help a business to minimise these risks and to try and catch these potential coding horrors before they're put in-front of the general public:
- Static Code Analysis (sometimes referred to as source code analysis) is sometimes a quick win here, but of course not the silver bullet. Sometimes a bug cannot be easily identified by just looking at code for common mistakes, it takes a skilled eye or even dynamic analysis for it to be spotted. However, static analysis can be added into your production pipeline and workflow, checking on each push for any newly added vulnerabilities!
- Automated vulnerability scanning/testing is also something else which can be done in-house usually, with the right tools. There is no reason why you shouldn't be running various security scanning tools against your application during testing/pre-production, such as web application scanners or even fuzzers.
- Go external, and get a 3rd party to penetration test your application if it requires that level of scrutiny. There are plenty of smart folks out there who do it day after day who can do this for you.
You can also deploy thing post deployment of course (depending on what you are coding!), so for web applications, a WAF (web application firewall) is sometimes useful to stop the vast majority of automated attacks. The alerts from this will also give you a very good idea of what is out there and at what scale you are being targeted.
I'm currently working on a side project [1] which is to try and identify breaches once they have happened, as unfortunately they are almost inevitable. It isn't always your code which lets you down! It may be a dependency or library, or even a simple phishing email. Put simply, my project produces a canary to add to your user base, that we'll monitor continually for a number of tell-tail signs that someone else may have a copy of your data.
At that point, it's time to invoke your incident response process! Or... get someone in to run that process for you.
>There is no reason why you shouldn't be running various security scanning tools against your application during testing/pre-production, such as web application scanners
Likely one reason is cost. When each individual tool costs 10k+ with the vendors trying to throw in consulting, it adds up.
Of course, there are things out there which can help a business to minimise these risks and to try and catch these potential coding horrors before they're put in-front of the general public:
- Static Code Analysis (sometimes referred to as source code analysis) is sometimes a quick win here, but of course not the silver bullet. Sometimes a bug cannot be easily identified by just looking at code for common mistakes, it takes a skilled eye or even dynamic analysis for it to be spotted. However, static analysis can be added into your production pipeline and workflow, checking on each push for any newly added vulnerabilities!
- Automated vulnerability scanning/testing is also something else which can be done in-house usually, with the right tools. There is no reason why you shouldn't be running various security scanning tools against your application during testing/pre-production, such as web application scanners or even fuzzers.
- Go external, and get a 3rd party to penetration test your application if it requires that level of scrutiny. There are plenty of smart folks out there who do it day after day who can do this for you.
You can also deploy thing post deployment of course (depending on what you are coding!), so for web applications, a WAF (web application firewall) is sometimes useful to stop the vast majority of automated attacks. The alerts from this will also give you a very good idea of what is out there and at what scale you are being targeted. I'm currently working on a side project [1] which is to try and identify breaches once they have happened, as unfortunately they are almost inevitable. It isn't always your code which lets you down! It may be a dependency or library, or even a simple phishing email. Put simply, my project produces a canary to add to your user base, that we'll monitor continually for a number of tell-tail signs that someone else may have a copy of your data.
At that point, it's time to invoke your incident response process! Or... get someone in to run that process for you.
[1] https://breachcanary.com - If you get this far, I would absolutely love any feedback.