Lately, we’ve faced some interesting new challenges. Security layers are being implemented more frequently in the Software Development Lifecycle and this leads to issues that were not present before:
- Too many false positives that need to be verified
- The actual development pace is greatly reduced
- A ‘feeling’ that the app security is still lacking
On the first two issues we can write several books, however, this article will focus only on the gut ‘feeling’. This feeling that the app security is lacking is as common as it gets, as developers test the automated scanners but are not convinced.
These automated scanners can be located either at code level (SAST), or ones that are executed in a test environment (DAST), and lately some solutions that combine both worlds (IAST). More often than not, third party dependencies are served from a software that also scans them (JFrog).
Without going deeper into the rabbit hole, the new DevOps that became DevSecOps, with layers of security at each step, with also security layers located outside that monitor the existing scanners and so on.
Yet is still somehow not enough. Or in some cases, it feels like ‘too much effort for little success’.
So let’s see what can we do, to be more confident in our application’s security posture.
Mitigation Strategies
The most important one that is also a easy decision, and at the same time impossible to do:
Turn off unused features
This is one of the easiest solution out there. Because security comes down to a mathematical concept, as fewer points of entry easeir to secure the application. So an application that has only one public point of entry is not necessarily inherently safer, but exponentially easier to harden its security.
To mention a few points of entry:
- User inputs (form fields, file upload interfaces)
- API endpoints
- Database connections
- Authentication systems
An application becomes dramatically easier to secure when for instance, APIs are internal-only rather than publicly exposed.
In this example, a banking application with a single authentication portal and limited transaction inputs is far easier to harden than one with multiple entry points like public APIs, extensive user profiles, and document upload capabilities. With fewer inputs to validate and monitor, security resources can be concentrated more effectively.
Like I said, is not this is the easier to do, but sometimes impossible, because in case of a complex app, it is required from clients to add more and more points of entry. However, point stands and if metrics show that a input is not really needed, or a functionality that represents a large point of entry is not used as expected, the most secure way is to just simplify that functionality, or remove it completely.
Prioritze Security Efforts: Legacy, Current, and Future Code
For example a large application that had a pentest two years ago should focus more on entrypoints that were added since then. Security resources are limited, so directing attention to newly introduced code can be a better use of resources.
Pre-Commit Hooks
Different mitigation strategies that can taget legacy and future code. Pre-commit hooks, configured properly, will simultaneously addressing both historical vulnerabilities and preventing future issues.
This is as simple as configurating a linter or prettier, only instead of only beautifying the code, you can easily add something that feels like a ‘pre-filter’ of security: catching plaintext passwords, or api keys, or various missconfigurations. And people reading this will think “really, exposted passwords”? You will be surprised how many successful hacks are due to exposing public files that were meant to be private, or storing plaintext password.
Code Review
For a more future-focused protection, code review automation might be just the thing. Combining automated pr scanning with a human touch might actually remove that ‘feeling’ of the app not being secure enough.
Conclusion
Ad-hoc testing strategy is not a good strategy. So, taking some time just to plan things out might be beneficial. Especially nowadays with so many methodologies (OWASP, MITRE ATT&CK®), security testing frameworks and automated testing strategy.
