I get asked all too often:
What do <insert big co.> do for AppSec?
Many organizations with mature AppSec programs recommend implementing a security champions program for security training.
A consistent AppSec program commonality is DevSecOps all-the-things, resulting in a lot (if not all) of AppSec engineer time and attention given to the CI/CD Pipelines - and not much on the developer experience or broader SDLC.
A fatal flaw in AppSec is thinking we need automated tools to be secure, the truth is often the very opposite in practice.
A security champions program is a way for elected developers to bond with security professionals and learn detailed security best practices that can be shared with their broader scrum team. This program also acts as a force multiplier for security teams with limited bandwidth.
Some developers might benefit from instructor-led security courses while others might like on-demand courses or hands-on training tools like Security Labs.
Why is DevSecOps a problem for AppSec?
The concept of DevSecOps is:
If security tests run automatically, developers can fix code immediately instead of waiting to hear back from the security team.
Sounds perfect, but there is a massive misconception here; If 'fix code immediately' is our goal, then the implementation need to be automated where lines of code are written. That is simply not in a CI/CD Pipeline. If this is not clear to you, look at any merge of code awaiting to be merged (or if there are no merge gates look at the last merge), then consider asking the developer what any single line of code in that merge was all about (why this syntax and not some other, what business function does it relate too, is it reusable, why, why not, all basic questions for any change) - you will quickly identify the developer will be on a new task, their context of the change has been lost, and it is a considerable effort for the developer to shift context and focus on what you are asking - particularly because the questions has come to them unplanned and interrupts the current work they are doing (which could lead to defects in that work)
So let's think about this for a moment. If DevSecOps is not immediate feedback and is very easily a risk in itself to the developers ability to do the business as usual work - it is not hard to accept that automation of security in pipelines is something developers actively avoid, and for good reason, they may not think of it as a business risk but it is.
Is there a place for Automated scans in pipelines?
Automated scans ensure more frequent scans and a steadier cadence.
When developers have to scan manually, it's easy to forget about a scan or intentionally skip a scan to save time.
The scan in the pipeline will provide assurance, if the organisation is interested in this. But alone can be far too noisy and disruptive, providing little assurance and often achieve the opposite intention (low confidence)
The only way we are able to ensure that our Automated scans actually provide assurance, is if the scans are properly tuned to have low false findings, and low true findings.
We can achieve the last point easily if we also scan before our pipeline, in our local environments when we are writing lines of code, and developers can fix code immediately when a defect is uncovered. This way the Automated scans can essentially be silenced.
Tuning AppSec Tools
Tuning is a challenge for every organisation. Exceptions, sharing rules, state, reporting.
What kind of activities are part of AppSec?
AppSec is a process, so what kind of activities are part of this process?
In many AppSec programs there are Application Security Engineers who support the Engineering capability of the organisation. While these AppSec Engineers can perform many of the same day-to-day tasks as most other Engineers, they do not actually do the same kind of tasks because if all Engineers were doing what an AppSec Engineer is doing there would be no need for an AppSec program or AppSec Engineers. Meaning Engineers will need to level-up, and here are the key areas to form a good AppSec program;
- Empower engineers be more security-minded when doing normal engineering tasks, using Threat Modelling and Secure Code practices via self-paced Labs or 1:1 outreach programs
- Identify ways to automate the security tests into the IDE (or developer local environment build process)
- Address unplanned work relating to security
Why do we do these activities?
- Engineers know the application better than anyone else in the organisation, you must empower them to address defects rather than gate them off from Engineers and secret them away in the Security Team
- Engineers don't have to manually run tests and ship reports for the Security team or take time away from being creative to address a defect that has lost context long ago, because the work was done by others, or was worked with long enough time to pass that the context in-mind has been replaced by newer work
- This will free up developers time reporting to and reacting to Security Team related tasks like vulnerability triage and compliance reporting for Vulnerability Management. Developers who adopt AppSec will introduce far fewer defects into the code and this will significantly reduce the findings by Penetration Testers and other scanning efforts by the Security Team coming back later to slow down Engineers
Successful software organisation empower engineer agility. Read about this on the Veracode Blog; Balancing Speed and Thorough AppSec Coverage
What are some ways you can save time on AppSec scans? If you have scans that can be effectively implemented early, implement them early. If you don't currently automate your AppSec scans, automate them.
Automation is not only a deployment security gate, but that seems to be the favoured option by many organizations who misinterpret some compliance obligation somewhere and developers suffer without
The following section talks directly to this point.
With the DevOps movement we see the word automation and all too often automatically (huh!) think that means CI/CD pipelines. However this is a myth of DevOps and automation takes many forms.
The AppSec form of automation is simply automating reparative tasks when writing code. This is done mostly within the IDE itself or as part of a build process on the developer local environment (not in a pipeline much later after code is 'done')
I critical method of avoiding defects in code is to automate the detection of defects when the code is being written. This includes identifying vulnerabilities in dependencies at the time you chose to integrate them so you are not wasting significant time integrating a dependency with a bunch of application logic only to learn much later it has a serious vulnerability or license incompatibility that prevents its use entirely and you must rip-and-replace starting again from scratch and with a new dependency that brings a different set of method calls or API.
The above is common, no it is frequent and inevitable, when you adopt DevSecOps or push security left - to the pipeline - but it is not something that should ever happen when you have good AppSec because it is essentially avoided.
To do much of this we need good tools.