What Developers Need to Know About the Strategy of Security

Cole Grolmus -

Application security is changing in dramatic ways. Change is accelerating so quickly that the current state is almost unrecognizable to someone who started developing software just a decade ago.

Rapid change can be a tough pill to swallow for developers. Anyone who writes code continuously faces change on multiple fronts: new technologies and frameworks, programming languages, tools, processes, and more. It's hard to keep up with core software development topics, let alone (arguably) adjacent topics like application security.

When looking at major trends in application security, one thing is clear to me: there is a lot more good news than bad news. That's not to understate the bad news — there is a lot of it. You know that. But there's another side to the story.

Challenges create opportunities. That's exactly what is happening in application security if we zoom out and look big picture. Strategy-minded software developers are exceptional at solving problems and taking advantage of opportunities. We're going to discuss a bunch of them today.

In this article, a few trends we'll cover include:

  • DevSecOps and the convergence of application security responsibilities on development teams

  • Changes in attack patterns inside and outside of your code

  • Developer-friendly application security testing

  • The rise of software supply chain security into the spotlight

  • The biggest risk people don't talk about: secrets management

  • The importance of securing data, not just code

  • Transformative progress in authentication and authorization

  • Reliance and impact of third parties on security

  • Changing user expectations around security

This is a wide-ranging article that covers nearly every area of the application security landscape. Since we're going wide here, this article is structured a bit differently than a typical company-focused analysis. Our goal for today is to cover a lot of ground while offering some practical ideas to explore.

Let's get to it.

Convergence is making developers responsible for more than development.

Impact

The convergence of development, security, and operations are shifting everything straight onto the plate of developers. Traditionally, software development has been all about writing, testing, and deploying code. Now, DevSecOps (and more importantly, the processes and tools behind it) are shifting more responsibilities and control to developers. Developers are still in charge of code, but now get to claim responsibility for infrastructure, security, and more.

On the surface, an increase in responsibilities sounds like a bad thing. It can be, but the reason why it's happen matters. When you look at the trend more closely, it's happening because improvements in tools enabled the shift.

Tools are getting better to help make this burden manageable — perhaps even advantageous. In the case of security, many new products are composable. They give developers a set of primitives and workflows to build security experiences instead of implementing one-size-fits-all products.

One good example is Persona, a set of building blocks that lets developers build specific identity verification workflows for customers. Another is Panther, which lets developers build a highly customized SIEM based on a set of log management and alerting primitives.

Forward-thinking security companies are going to continue building tools that are developer-friendly. Expect more of this in the future.

Ideas

The convergence of development and security is going to continue. Embrace it. The trend will accelerate as new paradigms (and products) gain adoption.

As the famous Eleanor Roosevelt quote goes, "with freedom comes responsibility." The traditional mindset for security has often been to buy a product that (theoretically) solves a set of security problems. Convergence and composability turns that around.

Now, we get a nice set of tools that we are responsible for using to build solutions for our unique security problems. That's a good shift, but a big shift that many people aren't ready for.

Finally, be development teams should be intentional about adoption and use of processes and tools. Don’t let them be imposed by security teams. Instead, work together on objectives everyone agrees on. This trend brings a window of opportunity to redefine the relationship between development and security (and to pick world-class tools), so make the most of it.

Attacks are happening outside of your applications...

Impact

Attackers are after your customers and money. Exploiting applications is only one of many ways to get there. Unfortunately, attackers are always on the lookout for new and creative ways to carry out their nefarious motives. Attacking your applications is a tried-and-true approach, but recent high profile breaches have involved adjacent areas of software engineering.

For example, attacks on the DevOps pipeline have caused major breaches, including SolarWinds. The InfoSec community has rightfully placed a lot of emphasis on securing code. However, examples like SolarWinds have shown us that other parts of our engineering processes are also targets.

Attacks coming from all angles also have an operational impact, even if a breach is avoided. According to data from Verizon's 2021 Data Breach Investigation Report (DBIR), Denial of Service (DoS) attacks cause a disproportionate amount of incidents (but not many breaches). Unfortunately, we now need to anticipate a steady stream (and sometimes a huge spikes) of attacks that follow this pattern.

Ideas

Broaden your mental model of security beyond code. Attackers are looking for any ways to exploit your company that they can find. We have to adjust our own mindset and include areas outside of code in our threat models.

Use services like DoS mitigation and bot management. These attacks can’t be eliminated, but their impact can be reduced. Services like Cloudflare routinely mitigate large attacks. The nominal cost of adding this layer of protection to our apps is well worth the investment.

Include your DevOps pipeline in threat modeling activities. Tools like CI/CD, artifact repositories, and other parts of the pipeline are now targets that need to be secured just like our code and infrastructure.

…but basic web application attacks still cause 26.1% of breaches.

Impact

Web application attacks are the second most frequent attack pattern identified in the Verizon DBIR report (social engineering was first, causing a full 33.6% of breaches). Attackers are looking beyond applications, but our applications are still under attack. And they're still causing breaches at an alarmingly high rate.

An upward trend in credential stuffing is a newer development for specific types of attack patterns. According to the Verizon DBIR, credential stuffing (~80%) causes far more incidents than vulnerability exploitation (~20%). Many people don't expect that ratio — especially given how much visibility and education there is around vulnerability exploitation.

From a process and governance standpoint, vulnerability management programs are converging with application security and risk management. These domains used to be viewed separately, with vulnerability management focusing on patching and risk management focusing on audits and compliance. Companies are now taking a risk-based approach to vulnerability management and managing application security vulnerabilities within their overall programs.

Ideas

Move beyond manual testing and one-off static code scanning. In today's iterative, fast-moving style of software development, a point-in-time scan or manual review isn't able to keep up with how fast an application's code is changing. Ideally, secure your code as it’s written. As we'll discuss next, major improvements in tools have made an iterative and developer-friendly approach possible.

Use services to detect and defend against credential stuffing attacks. This attack pattern is still an attack on our application, even if it's a different approach than more traditional vulnerability exploitation. We have to expect a constant flow of credential stuffing attacks on production applications, including the occasional spike in attempts when a fresh batch of credentials gets exposed in a breach.

Take a prioritized and risk-based approach to remediating vulnerabilities. As much as we'd like to close all vulnerabilities, it's currently impractical for most companies to do this in practice. A risk-based approach makes remediation more manageable.

Application security testing is (finally) becoming developer-friendly.

Impact

Organizations (and products) are finally starting to cater security to developers’ needs. For any experienced software developer, this has been a long, long time in the making. The painful memories of application security intake forms, delayed releases, and last-minute vulnerability remediation haven't faded away quite yet, but a lot of progress has been made.

The big idea is to move application security testing forward in the development process and iteratively run scans as code is developed and committed. The term "shift left" gets overused, but the foundational idea is nice. Just like you'd write automated tests and get real-time feedback, you can run automated security tests.

Companies like Veracode and Snyk have been leading the way, and both companies are likely to be rewarded with IPOs in the next five years. Their success (and huge developer fan base) validates the idea that software development can increase speed and security at the same time — these objectives are not diametrically opposed.

Ideas

Forward-thinking engineering teams obsess over simplifying the process of writing secure code. As Snyk founder Guy Podjarny recently discussed in a Human Layer Security podcast, "you have to care about something more than it burdens you." This quote concisely defines the value of products like Snyk. When we make security easier for developers, they're more likely to embrace it.

Podjarny also discusses the idea of decentralizing application security. The legacy paradigm was for information security teams to fully own application security testing. Naturally, this created a bottleneck as software continued eating the world and companies wrote more and more code. Modern application security tools make decentralization possible and help turn security into a shared responsibility between engineering and security teams.

Finally, invest in modern application security platforms. Progress in this area is enabled by tools. They're surprisingly affordable to adopt, especially considering the impact they can make on your company's security posture.

Software supply chain security isn't under the radar anymore.

Impact

Log4j (Log4Shell), NPM libraries (colors/faker), and other high profile vulnerabilities brought software supply chain security straight into the spotlight in 2021. Even the President of the United States is talking about it (and taking action).

In hindsight, the emergence of this trend should have been obvious. We have relied on open source packages for years. The relative degree of calm and stability in the security of the software supply chain wasn't going to last forever — it was only a matter of time before packages became a more frequently used attack vector.

Help is on the way. A new generation of early stage startups has raised $10.6M in the past two quarters, mostly at seed stage funding. It will take some time for us to wrap our collective minds around the lessons learned from the 2021 vulnerabilities and what we need to do differently. However, the pace of innovation and progress is going to move quickly.

Ideas

First, we have to deal with immediate lessons learned in the near-term: prioritize finding and remediating vulnerable packages in your apps. This is another place where tools like Snyk or Github Dependabot can help. Automate the search for vulnerable packages as much as possible, then work on making remediation more efficient and automated.

Watch for emerging companies in this space. As I said earlier, help is on the way. Chainguard is one example of a recently-funded company that is building an innovative product with an experienced team.

Finally, explore emerging approaches like SLSA and Sigstore. These projects are going to take some time to evolve and become directly actionable. However, it's worth investing a little attention to about the latest ideas so that you're prepared when they reach mainstream adoption.

Managing secrets is the biggest risk people aren't talking about.

Impact

For all the talk (and grievances) about passwords, we spend very little time talking about managing other kinds of secrets. Things like API keys, certificates, and other non-password forms of access control escape the spotlight. They're just "things developers use" to a lot of people.

In a 2021 1Password survey, 80% of IT/DevOps organizations admitted to not managing their secrets well. That's...not great. It's also a more pervasive problem than you'd think. In the same survey, 65% of companies reported having over 500 secrets, and 18% have more than they can count.

Having over 500 secrets (or more — who really knows, right?!) that aren't managed well is obviously a bad situation. Secrets can grant powerful access to a lot of sensitive information, as we saw recently with the token-based attack on GitHub accounts. There is already better visibility and momentum behind protecting secrets. Attacks like these make the idea of protecting secrets even more visible.

Ideas

Make good hygiene around secrets part of your engineering culture. If we don't talk about protecting and managing secrets, we can't expect people to keep them secure. Secrets need to be part of your security discussions and actions.

Part of the solution is using a a secrets management service. There are several good ones now, including products like CyberArk Conjur, HashiCorp Vault, and 1Password Secrets Automation. GitHub also builds basic secrets management right into Actions workflows.

Finally, effective discovery of secrets before implementation of a product is a worthwhile project. You can't protect the secrets you don't know about, and finding them is tricker than you'd think. Secrets get embedded in source code or stored in config files all the time. The best approach is to make discovery a project, come clean about what you find, and protect your secrets the right way going forward.

Securing data and securing code are equally important.

Impact

Many common attack patterns bypass the application and go straight to data stores. More than ever, we have to think about securing access to data outside of an application itself. According to the Verizon DBIR, attackers are most often after credentials (for privilege escalation), personal data, bank data, and confidential internal data.

Privacy regulations have also created consequences for mistakes. This raises the bar for protecting data and making sure it's only accessible by the people who need access. It's not worth putting development teams at risk by giving them excessive access to production data if it can be avoided.

When designing applications today, you need to factor data security into your architecture. How you protect the sensitive data is part of the overall solution — privacy by design. Designing an application is hard enough already, but data protection is definitely part of the thought process now.

Ideas

Be part of the solution for securing data. Don't leave the responsibility to infrastructure and security teams. It's still important for development teams to write secure code, but not at the expense of ignoring data security entirely.

Explore emerging approaches and products that allow developers and data scientists to work with sensitive data securely. JumpWire and Sarus are two companies from Y Combinator's recent W22 batch who are working on this problem. There was also a great Not Boring article on Evervault, another interesting company building encryption infrastructure. We're a long way away from de facto standards, but I'm hopeful about progress.

We're in a golden era for authentication and authorization.

Impact

Seriously. The options available to developers today for authentication and authorization are amazing. And they're getting better by the day. Companies like FusionAuth, Transmit Security, Stytch, and others have built world-class, developer-friendly authentication products that are breathtakingly simple to use.

Users are also becoming more familiar with new authentication factors. We're still a long time away from full-blown passwordless adoption, but upgrades like magic links are starting to become more natural for non-security people. This is a good trend because mainstream adoption allows us better options than passwords alone.

Finally, external authorization is becoming a viable option with the new generation of products. This trend is still a long shot — color me skeptical about applications fully externalizing authorization (especially existing ones). However, another round of companies is building products that could make the job easier.

Ideas

It's been said before, but I'll say it again: don't roll your own authentication. There are all kinds of legitimate reasons why your application could be attacked and breached. Building your own auth is taking an unnecessary risk — it's essentially an anti-pattern in 2022. Use an external service or a well supported open source package like Devise (for the Ruby on Rails community).

Give users the option of passwordless or Multi-Factor Authentication (MFA) when authenticating to your application. Using external authentication platforms makes it a lot easier to do this. The added security benefit for your users is well worth the minimal effort required to implement it.

Finally, explore whether external authorization makes sense, but do it with care. Handing over your authorization to a third party is a lot riskier than using standards-based authentication from a third party. However, it's better than making a mistake with building your own authorization.

Security posture is highly dependent on third parties.

Impact

In the SaaS and cloud-based world we live in, our security relies on third parties more than ever before. We host our applications on large cloud providers. We rely on services for everything from UI frameworks to chat to analytics and more. I literally just recommended using a third party for auth. You get the idea — we're all intertwined now. Our security depends on each other.

Of course, the size and scale of risk and potential impact varies by service. Vulnerabilities in cloud services have macro-level risks and impact across the entire tech industry. Services like Mailchimp are somewhere in the middle. They have a lot of customers, but in the recent example, only a few were exploited.

Other point solutions are smaller in scope. Some have potential customer impact (e.g. downtime of a chat service) and others only impact employees. Mileage varies.

We still own significant responsibility for security, even though it’s partially out of our control. It's important to be aware of how far this trend has gone and how dependent many of us are on third parties now. By acknowledging this reality, we can make sure we take the right steps to protect ourselves.

Ideas

Know exactly which third party services your apps are using. This is a similar idea to protecting secrets — you can't do anything about securing third party services if you're not aware of them.

Make security part of your buying process for third party services. It's a lot easier to evaluate security before you're using a service than after it's deeply embedded in your application. Or worse, after the third party service has been breached and you're dealing with the consequences.

Finally, it's important to know that third party assurance reports (like SOC2) are useful, but do your own homework. It's unrealistic to expect that auditors will catch every security problem. For many third party services, there are also unique circumstances about your use cases that can go beyond the scope of the audit.

For many users, security is a feature now.

Impact

Trust and safety are quickly becoming and important part of product design. Repeated news headlines about data breaches, election security, social media, etc. have elevated security, privacy, trust, and fraud into the public eye.

Expectations are higher if an application involves user-generated content, money, or sensitive data. The experience of dealing with bad things that happen in your application — or outright preventing them from happening — is very important for a lot of people.

Ideas

Implement trust and safety processes, even if they’re basic. Something is better than nothing. However, you should be prepared to build significantly more robust features if your customers have higher expectations.

Stretch your companies’ boundaries for transparency around security and privacy. Companies like Trustpage and Cinder are building a new class of products for trust and transparency. When done well, this approach is a strategic advantage that can differentiate your company and products.