Application Security: We can do better

Guest Post by Arnica CEO Nir Valtman

I recently had the opportunity to meet and converse with Nir Valtman, CEO of Arnica. His thoughts and insights regarding the future of application security are fascinating. Check out this guest post from Nir Altman, CEO of Arnica. — TCW Editor

A significant amount of innovation is going on in application security today. Modern, cloud-based, rapidly iterated development models have spurred a once-in-a-lifetime shift in how application cybersecurity must operate to secure our systems properly. By examining fundamental shifts in the infrastructure and development world in detail, we can gain a critical understanding of how the application security landscape must change to keep pace.

Eliminate code risks (SAST, SCA, IAC), hardcoded secrets, excessive permissions, and dependency vulnerabilities with Arnica

Fundamental Changes in Our Approach To Software Development

Changes to software development approaches in the last decade necessitate an update on how we secure developers, the code they write, and the products they build. From architecture to build-systems and development models, there is a new way of assembling applications and a brand new set of underlying infrastructure design paradigms. The following changes are exciting to me from an application perspective and scary from a security perspective.

• Cloud-native and cloud-based architectures have abstracted away the bulk of underlying infrastructure requirements when building applications. We no longer have to stand up hardware, operating systems, and middleware to ensure the application runs appropriately. Cloud computing and cloud-native models, such as serverless, allow developers to focus on code creation rather than the underlying infrastructure requirements.

• Microservice and API-driven applications are born from a modern approach to application development where we build to a minimal feature specification and create interconnected API-based communication between application components. This microservices approach allows developers the flexibility to leverage cloud-native scale and growth models within their applications.

• Infrastructure-as-code is a programmatic approach to cloud infrastructure creation and management. Standardized templates and approved infrastructure configuration specs enable developers to safely and predictably create, change, and improve infrastructure.

• Saas-ificiation of libraries and outsourcing features to external APIs accelerates development when writing services that don’t require reinventing the wheel. When you link a microservices approach to application design with the usage of external API-based services, you can very quickly assemble your application and its underlying infrastructure and build new and exciting iterations of your application faster than ever before.

With all of the changes to how applications are built and deployed, we can't rely on traditional application security approaches developed over 15 years ago or even 5 years ago and expect that they will work in the modern application environment. In just the past few years, new trends have taken hold – such as “shift left” – that still don’t solve the same old issues. It's time that we, as application security professionals, get smart about modernizing our application security approach. 

Security Assessment In the DevSecOps Pipeline

Security in a traditional pipeline is connected to the build system and executed during the build cycle. The issue that this brings up is that some forms of an application security assessment are time intensive, meaning that the time they require to execute does not fit into today's rapid development pipeline model. For example, the larger the code base, the longer it takes to complete a static analysis assessment. There has to be a better spot within a modern pipeline to execute our static analysis, composition analysis, and license assessments. With the advent of git-based source code management (SCM), we have a new location where application security can and should occur. Relocating security assessments from build to code push removes the time-related issues of application security assessments and detects risks earlier.

What we USED TO do: Security assessment at build time in the build pipeline.

What we SHOULD do: Pipelineless security assessment at code push in the git-based source code management.

Shift Left? Shift What Left? 

The “shift left” movement of the last few years espouses the idea that application security must push security assessment into the hands of the developers so that by the time the official build occurs, there are hopefully zero build-breaking issues. The idea was to find ways to automate security assessment, such as doing static analysis on the developer's laptop and requiring it to happen before code is committed to the repository. 

It turns out that all versions of "shift left" are not created equal. Traditionally, shifting left moves security tasks – that developers might otherwise want to avoid – directly into their daily to-do lists. Ultimately, it is the “work” that is being shifted left to developers. Unsurprisingly, this negatively impacts developer culture when you factor in the time implications on developers, who are generally more excited by building new features than fixing security issues. 

If instead of shifting "work" left, we shift "detection & automation," we get an entirely different result: developer delight! Automation is the key to minimizing effort and maximizing security impact from developers (or security teams) when implementing security fixes. The ideal end state is application security that stays out of the way until it’s needed. When a vulnerability is detected, a security tool should be helpful to the developer, not harmful to their development velocity. 

AppSec wins if we can make security delightful to the developer and still get bugs fixed quickly and correctly. The right way to achieve this is to focus on locations within the development process to create one-click automated remediations so that we can implement security that is helpful to developers. It has to be timely and fast and lower the day-to-day work effort of the developer.

What we USED TO do: Move security work into the hands of the developer "shift left."

What we SHOULD do: Move automated risk mitigations into the hands of the developer.

The Movement to GitOps and Chat-Based AppSec

Another position of the shift left movement was to put all of the interactions with the developer directly into the tools and systems they already use daily. For security, that meant pushing discovered vulnerability details into the bug tracking or ticketing systems. In a few cases, this had positive results, but in most cases, developers don’t actually prefer to be in their ticketing tools. To be successful, application security tools have to live where developers live. Developers prefer to spend most of their time in their IDE, their code management platforms like GitHub, Azure DevOps, GitLab, or BitBucket, and their collaboration tools like Slack or Microsoft Teams. So why haven't we rebuilt our application security systems to integrate into these modern application tools much tighter? It's high time we focus on bringing security to the developer interaction models in use today.

What we USED TO do: Vulnerabilities surfaced in Jira tickets or external AppSec tools.

What we SHOULD do: Vulnerabilities surfaced in collaboration tools or next to the source code.

Not All Risks Are Equal

A more modern infrastructure has opened the door for security tools across the industry, application security included, to shift toward mass visibility of risks. On the surface, this is a positive change – you can’t fix what you can’t find. However, there are some serious unintended consequences to this approach that require immediate course correction. 

But at this point, being blind to the context of risk in the software development process is willful ignorance. By integrating with the git-based source code management (SCM) tools, application security solutions can leverage key contexts such as who pushed a commit, the business importance of the repo that is being committed to, and more. So why not use that context to make our application security tools better? 

By understanding the context of a risk, we can embed that context in the risk alert itself to prioritize it effectively. Find a vulnerability in a third-party dependency? That could either be a high-severity risk that needs to be addressed immediately because it’s in a repository with critical business importance… or a far lower priority because it was found in a non-production branch. 

What we USED TO do: Push all security alerts all the time. 

What we SHOULD do: Leverage a deep understanding of context and priority within an organization to surface the most important risks. 

The Role of Automation in Modern Applications

Automation is the only way application security can scale. Without automation, machine intelligence, and the ability to assist developers with rapid remediations, we can't expect security to keep up with the new faster pace of development. Without automation, faster development means more vulnerabilities, more security alerts, and bigger backlogs. We must create machine learning and artificial intelligence-backed systems that fix vulnerabilities way faster than humans can do today.

The possibility of breaking things is the typical pushback when we suggest automation-based improvements to application security. This apprehension is understandable, considering the developer time and effort needed to fix breaks in the pipeline based on past application security approaches. But this also ignores the time spent by developers making manual fixes today. 

The entire paradigm can shift if we can also dramatically accelerate break fixes – even providing an “undo” button in many cases. By implementing application security tools that live where our developers are (as suggested above), we can get to a point where it's ok to break things because we can recover fast enough to avoid business impact. An example would be a developer whose permissions are automatically removed from a repo they haven’t engaged in within six months. If reverting that change is as easy as an admin clicking an “undo” button or the developer typing “/need permission” into Slack, the temporary friction is usually palatable.

Automating mitigations is not always going to be the right model. For critical infrastructure changes or updating a library to address a CVE, for example, you may want to take a more gated approach. But for a large swath of risk categories in application security – permissions and secrets, as examples – a “break” caused by an automated fix carries low operational risk. 

What we USED TO do: Add it to the backlog and fix vulnerabilities one at a time using human time and effort.

What we SHOULD do: Stop new vulnerabilities from being introduced by automating remediation without adding unacceptable levels of business risk.

Application Security Modernized

Development tools, architectures, designs, and processes have all been modernized. Why have we not done the same for our application security approaches and tools? We must discard the long-held religious beliefs of traditional application security and define a new strategy.

In analyzing the fundamental changes that have occurred within our application development processes, it becomes apparent what must happen to level up application security approaches. Pipelineless security assessment occurs at code push, creating an environment where real-time feedback can happen in the development process. Invisible security delivers an idealistic vision where security is entirely in the background without impacting the development process. Security integration to modern tooling is an enabling technology required to reach the vision of invisible security. Chat-based application security makes security interactive at the moment if the developer needs it, and fully automated application security delivers the most direct and rapid improvement to code without relying upon human scale limitations.

Suppose we could create a world where these modernized application security concepts were implemented. We could build a world where software development can run entirely unimpeded by risk. With all the disruptive application security companies being born every day, we are well on our way to building tomorrow’s future today.