The 6 non-negotiables of reducing modern application attack surfaces

Today’s applications rely on countless code modules, APIs, dependencies, technologies, pipelines, developer tools, supply chains, infrastructure, testing frameworks, etc. Each of those components and their relationships to one another make up your application attack surface. And weaknesses in one or more components represent vulnerable access points for bad actors.

With just traditional tooling and manual processes, it’s nearly impossible for security teams to accurately map their application attack surfaces—especially for cloud-native applications that heavily leverage microservices, third-party components, and agile development practices.

• Manual processes like threat modeling and security questionnaires are valuable as point-in-time intel, but as applications change with weekly and daily releases, that intel becomes out of date fast.
• Application security testing (AST) tools provide slivers of insight into specific types of risks but often create noisy, contextless alerts that can distract and overwhelm teams and are siloed, preventing you from identifying toxic combinations of risks.
• Application security orchestration and correlation (ASOC) solutions provide a centralized view of risks but don’t provide holistic visibility into the underlying components necessary to get a complete picture of risk.

To better manage risk and improve their application security posture, teams must re-evaluate how to more effectively map and reduce their application attack surfaces at scale.

1. Build a continuous code-based inventory

Without knowing what you have in your codebases, you cannot reduce the application attack surface and efficiently secure your applications. Building a complete and deep code inventory is the crucial first step to understanding and managing your application attack surface and its risks.

This requires scanning of all code, developer behavior, artifacts, dependencies, libraries, configurations, technologies, sensitive data, APIs, and more across the history of your organization’s codebase and software supply chain—including proprietary code and open source components. From this initial inventory, you need to be able to understand the relationships between components, how they change over time, as well as their runtime manifestations, associated risks, and code owners.

This, extended software bill of materials (XBOM) gives you the foundation for contextualizing risks to determine the potential likelihood of them being leveraged for an attack and the impact on the business in such a case.

2. Layer in risks to build an application risk profile

The next step is to consistently ingest, analyze, and contextualize data from third party sources such as:

• application security testing tools (SAST, SCA, DAST)
• cloud security testing tools (container, CWPP, CSPM, IaC security)
• manual processes (penetration testing, bug bounty programs, compliance reviews, etc.)
• intrusion detection and prevention systems (IDPS) and authentication systems
• configuration management databases (CMDB)
• bot protection solutions

Once you have those insights aggregated and connected in the context of your inventory, you will have a more complete picture of your application attack surface and the complex relationships within it. Only then can you start to build an application risk profile—a comprehensive and continuous assessment that outlines the potential security and compliance risks associated with a specific application.

By discovering and mapping every component, identifying security risk across these components, and contextualizing this risk with insights from disparate tools, you have the blueprint for understanding the evolving nature of risk.

3. Assess, cut, and control attack surface sprawl

Once you have a foundational attack surface mapping, you can assess areas of sprawl. Attack surface sprawl happens when no policies are in place to regulate the types of components incorporated, making it harder to manage them and increasing your application footprint, thus the attack surface and risk. Sprawl may come in the shape of risky elements and patterns, like an excessive amount of frameworks, various different programming languages or inconsistent code structures, unnecessary components or integrations, etc.

In order to control sprawl, you need to first assess it and start to make strategic decisions to shrink it, and turn those decisions into policies to prevent future sprawl. For example:

1. Five code modules with PII are using multiple encryption frameworks; these could be replaced with just one that is secure and properly configured; create a policy that ensures only the standardized framework is allowed.
2. A deprecated OSS package exists in a high business impact application; the package should be removed; create a policy that bars developers from bringing in depreciated OSS packages.
3. Several logging frameworks in a high impact application; standardize and consolidate logging frameworks; create a policy that ensures only the standardized framework is allowed.
4. Multiple internet-facing APIs that expose PII; consolidate these APIs and use an API gateway; create a policy that triggers a security code review or a penetration test when sensitive PII data is involved in the API.
5. Large number of CI/CD pipelines delivering high business applications to AWS; centralize pipelines for streamlined processes, better resource allocation, and reduced complexity; set a policy that triggers an alert when a pipeline is configured or added.

As development plans evolve, development teams change, developers leave, or features are depreciated, code components can be forgotten and abandoned in the codebase. These components carry risk with no reward, so it’s critical to quickly identify and disable any unnecessary services, ports and components. Removing redundancies, inconsistencies, and inefficiencies reduces complexity and minimizes entry points, making your attack surface cleaner, more secure, and easier to maintain.

4. Contextual risk prioritization and remediation with ASPM

Identifying, prioritizing, and fixing risk can significantly reduce the application attack surface and costs to the organization. However, the key to doing this accurately and rapidly depends on your ability to intelligently correlate findings and prioritize based on your unique business needs. Easier said than done, right?

Not necessarily. Application security posture management (ASPM) aims to solve this challenge by integrating and analyzing security signals across software development, deployment, and operations.

Traditional application security testing and processes can help identify potential and existing vulnerabilities, weaknesses, misconfigurations, and material changes, but they’re typically siloed and/or lack the context of where they are in an application and what the potential impact on the business would be. With an ASPM solution, all these findings are correlated and enriched with development-oriented and business-specific context, so you automatically unify your risk visibility, prioritization, and remediation.

This approach automates risk assessment, so you can easily answer these questions about a security finding:

• Is it deployed?
• Is it a part of the final production artifact?
• Is it exposed to the internet?
• Does this vulnerability have a known exploit?
• What’s the blast radius across my application components? (how many are affected)
• Ease of remediation?
• Is it related to a high business impact (HBI) application?

The answers to those questions will determine how to prioritize risks to mitigate the most critical risks faster, ultimately accelerating your ability to shrink and proactively manage your application attack surface.

5. Automate triggers for risk assessment processes in design phase

Once sprawl is under control and you have a mechanism to define risk for your organization, you’re in the right place to begin proactively preventing your attack surface from ballooning—and you can do that before any actual software development begins. In the design phase, when R&D teams are scoping, architecting, and planning the design of a new application, feature, or an update to an existing feature, you can leverage the application context gathered in the previous steps to identify any proposed changes that may introduce risk or expand your attack surface.

Creating standards for secure design practices, tagging risky features early on, and automating triggers for security processes—like scheduling an agile threat model or issuing security questionnaire—empowers application security teams to seamlessly integrate security checks into the design process and ensure risks don’t slip through the cracks.

Engaging security in the design phase ensures that your application attack surface remains secure, resilient, and less susceptible to potential vulnerabilities and attacks, and saves time reactively addressing risks once they’re in production or even development.

6. Leverage context to implement risk-based developer guardrails

Of course, automating security is much easier when the source material is more machine-readable than natural language you might find in a user story ticket. Implementing developer guardrails and surfacing security feedback through automated checks as changes are being made helps proactively enforce security best practices and reduce application attack surface sprawl.

By defining and enforcing secure coding practices on each and every commit around specific programming languages, technology, architecture, and business requirements, you’re able to proactively control your attack surface. But without context, those guardrails can become noisy and prohibitive to developers trying to move fast.

That’s why taking a risk-based approach is key. By layering the contextual data from our inventory, you’re able to create, organization-specific, risk-based triggers to ensure the right-sized action in response to specific categories or severities of risk and strike a balance between security and development velocity.

Get started with this approach

In a complex, constantly-evolving threat landscape, application attack surface mapping and reduction are table stakes for adopting a proactive application security strategy—and the right partner makes it that much easier.

Apiiro empowers organizations to efficiently map and reduce application attack surfaces, contextualize security alerts, correlate and prioritize risks, and remediate faster. By bringing together the best of ASPM along with key application and software supply chain security use cases, XBOM generation, and graph-based contextual inventory of your application components, Apiiro takes a fundamentally new approach to application security.

⬩⬩⬩

Key Takeaways:

• Modern application attack surfaces are complex and interconnected; mapping and reducing them is key to improving your overall application security posture.
• The foundation for reducing your attack surface and profiling your applications is building a deep, continuous code-based inventory and consolidating risks in that context.
• Assessing, cutting, and controlling attack surface sprawl requires visibility and policies to enforce early in the development lifecycle.
• Relying on ASPM tools for contextual risk prioritization and remediation is a great way to streamline your application security and compliance.
• Automating triggers for risk assessment processes in design and development phases is the only systemic way to keep your attack surface under control.

To get started with Apiiro to see how our deep ASPM approach can help you map and reduce your application attack surface, schedule a demo with our team.