When users encounter software bugs, the consequences can range from annoying to brand-damaging to life-threatening. To quickly remediate the issue—no matter how big or small—it's important to know how, where, and when the bug was introduced. But it's even better to prevent the bug from ever reaching production.
To accomplish this, security must be built in from the very beginning of the software development lifecycle. To do that you need to adopt sophisticated testing, scanning, and continuous integration. These, in turn, require container image scanning, container layers, and linting.
Security has been developers' top challenge since software was first, well, developed. But back in the day, software was released and updated at what now seems like a glacial pace. Developers had more time to code and more time to fix problems with code. Today, organizations live and die by their ability to quickly and iteratively get new apps out the door—security (at times) be damned!
Of course, security can't be damned, but it also can't be allowed to be a bottleneck to providing customers a steady stream of new and newly updated apps and services.
Here's how to build in application security from the start while avoiding bottlenecks in your software development pipeline.
Complicating factors: Containers and everything else
Adding to the opportunity and the challenge is the ever-expanding growth in the use of the container model: Containers make it easy to build, package, and promote an application or service—and all its dependencies—throughout the entire lifecycle and across different environments and deployment targets.
But that also means that a security gap anywhere along the way can have a damaging, widespread ripple effect.
It's for this reason that the old saw "Security should be built in, not bolted on" is truer than ever. This is especially the case as developers build apps and services within increasingly complex environments, including, but not limited to, containers, legacy and cloud-native software on Windows and Linux operating systems, function-as-a-service (sometimes called serverless), virtualized infrastructure, public and private cloud infrastructures, and edge computing.
Manual security in the middle of all this? Good luck. Here's what you need to do instead.
Solution: Automate, test, scan
Adopting sophisticated testing, scanning, and continuous integration/continuous development (CI/CD) makes the process of securing code earlier in the process much easier. With automated CI/CD, developers and operations teams work together in an agile way to, among other things, ensure the active testing and verification of code as it's being developed.
The entire process of releasing code is developed, maintained, and improved as code.
In fact, this combination of testing, scanning, and CI/CD helps ensure that an app reaches production in an efficient and secure way. And because most modern software projects include code from hundreds of contributors and repositories from all over the world, it would be pretty much impossible to securely develop, test, and deploy new features without a CI/CD system.
But CI/CD alone is not enough to identify the one bad apple that spoils the whole bunch of code.
Going beyond CI/CD
Here are other tools and practices that your organization should be using to ensure that tainted code never reaches production.
Security testing
Just because an application runs on a developer's box or passes CI/CD functional and integration testing does not mean that the app won't get hacked the second it's put in production. Different types of tests can help determine where your holes are.
Static application security testing (SAST) is great for developers with code that doesn't even function yet. These tools look for problems such as buffer overflows, cross-site scripting mistakes, and SQL queries that are vulnerable to attack
Dynamic application security testing (DAST) is also useful, because not all vulnerabilities can be discovered with code alone. Many vulnerabilities don't manifest themselves until the code is running.
This could be because of infrastructure (load balancers, web servers, DNS, etc.), or just the way the code runs. DAST tries to attack the running application to determine if the application is vulnerable.
Container image scanning
Libraries and drivers (SQL, etc.) from the operating system bits in a container can be just as vulnerable to security issues as the code that developers write.
Static container image scanners provide developers with a way to catch known vulnerabilities using policies that flag issues at build time. This method uses lists of known vulnerabilities as they are discovered by the community—for example, the Common Vulnerabilities and Exposures (CVEs) list.
Real-time container image scanners recognize that trust is temporal. Just because you trust that an image is secure when you launch it doesn’t mean you can trust it three months or a year later.
Once you put an application in production, it may not be updated for months, which means that a container image rebuild might not happen, thereby introducing vulnerabilities to the application over time. Real-time image scanners can check the running images against known vulnerabilities.
Container layers
These can be used to separate concerns among subject-matter experts. Java experts know best how to configure a JVM for security and performance. PHP experts know best how to configure PHP-FPM for security and performance. The same is true with database experts, caching software experts, web server experts, and any programming language expert that relies on interpreters or virtual machines (Java).
Separation of concerns allows each team to provide its expertise at the layer that it knows best. After all, no one person can be an expert in everything—especially when security people are typically vastly outnumbered by developers, site reliability engineers, and system administrators.
Linting
Linting can be leveraged to analyze source code for bad syntax, readability errors (yes, this can slow security researchers down), and suspicious constructs.
Don't stop here
This list is just the tip of the iceberg. There are a number of other tools and best practices that you must put into place to ensure secure applications all along your code, build, and deploy pipeline.
As you have likely experienced, it's difficult to effectively integrate and apply one, let alone all, of these tools. And, of course, not doing so leads to more room for error. Security must be coupled with automation to ensure that nothing falls through the cracks in this increasingly complex environment.
Companies, therefore, need to be thinking about automating anything that can be automated through the use of tools such as Podman, Buildah, Ansible, Jenkins, and platforms that leverage Kubernetes orchestration.
Learning and leveraging strategic automation, teams can focus more on creating great code and less on finding out whether there are bad apples lurking within it.
Keep learning
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed fast on the state of app sec testing with TechBeacon's Guide. Plus: Get Gartner's 2021 Magic Quadrant for AST.
Get a handle on the app sec tools landscape with TechBeacon's Guide to Application Security Tools 2021.
Download the free The Forrester Wave for Static Application Security Testing. Plus: Learn how a SAST-DAST combo can boost your security in this Webinar.
Understand the five reasons why API security needs access management.
Learn how to build an app sec strategy for the next decade, and spend a day in the life of an application security developer.
Build a modern app sec foundation with TechBeacon's Guide.
