Complete Guide to Application Security

This application security guide is written to shed light on core application security concepts, explain the challenges associated with app security, and equip you with the tools and best practices you need to stay secure in 2023.

Why is application security important?

Applications, especially those that are cloud native, are a gateway to servers and networks and present an ideal attack vector for malicious actors. Since malicious actors continue to refine their methods to penetrate software, it’s crucial that security is an ongoing activity that’s deeply embedded in the development process. Application security best practices help uncover vulnerabilities before attackers can use them to breach networks and data. It's also important to consider application data security to ensure that sensitive data such as customer information is secure.

Vulnerabilities can originate from something as simple as a configuration error or using a software component that contains a known vulnerability. The issue is widespread: according to Snyk’s 2021 State of Cloud Native Application Security report, over 56% of organizations experienced a misconfiguration or known unpatched vulnerability incident involving their cloud native applications. While not all of these vulnerabilities present a major security risk, hackers themselves evaluate vulnerabilities to find which ones present a plausible method for penetration.

The most common issues are misconfigurations, and known, unpatched vulnerabilities

Organizations of all sizes should also be aware of the risk that misconfigurations pose, particularly those working with highly sensitive data (such as financial institutions). Application security is growing as a distinct market which Forrester analysts expect to reach $12.9 billion by 2025. To improve application security, companies need to implement a two-pronged approach:

• Implement the processes required for security, centered around a shift left security culture and a move towards integrating security into DevOps.

• Adopt the tools required for comprehensive security, including scanning tools that integrate with developer tools and workflows.

In addition to these tools and processes, developers and security teams can access a variety of resources to stay on top of application security, including organizations such as the Open Web Application Security Project (OWASP), a nonprofit that releases an annual list of the top web application security vulnerabilities. Snyk’s resources, including its State of Cloud Native Application Security report, further help developers navigate application security in the cloud native era.

Application Security Trends 2023

2022 is a watershed year for cybersecurity as organizations face greater and more complicated cyber threats. Organizations are focusing on cybersecurity in a few ways:

• CISO’s are taking a permanent chair in the executive suite. In the USA, cybersecurity is considered a matter of national security. In February 2022, President Biden signed the Executive Order on America's Supply Chains, which aims to strengthen cybersecurity support for critical sectors of the information and communications technology (ICT) industry. The conflict in Ukraine has further brought cybersecurity into the limelight given concern over potential cyberattacks sponsored by Russia.

• Despite their dedicated role, CISO’s are expected to deliver more with the same resources. This will require innovation in the areas of people, technology, and processes.

• Software supply chain security is increasingly important in the wake of the Log4J attack. Malicious actors continue to seek out compromises in open source code repositories or other links in the supply chain. Organizations are responding by identifying weak links and implementing better security measures throughout the supply chain.

• The proliferation of cloud native applications means cloud infrastructure and infrastructure as code (IaC) configurations need to be included in security and compliance considerations. Application security testing orchestration, which integrates security continuously with the development process, is a part of this overall cloud security posture. You need to ensure that you are covering all levels of application security, from your own code via dependencies, all the way through to cloud configuration.

What are the challenges of modern application security?

Modern application security is a wide and complex topic. We’ve boiled it down to five main challenges organizations commonly encounter:

1. Inherited vulnerabilities

2. Third-party and open source vulnerabilities

3. Adopting a DevSecOps approach

4. Finding qualified experts

5. Lack of a centralized management tool

Let’s take a deeper look at each of these:

Inherited vulnerabilities

Developers need to be aware of vulnerabilities they may introduce during the coding process, but some vulnerabilities are inherent in modern applications. These inherited vulnerabilities exist for a few reasons:

1. Software systems experience entropy — they are constantly changing, increasing in complexity, and in need of updating and improvement.

2. Prioritizing which fixes, updates, and maintenance activities are most important is a vital and ongoing effort.

3. Legacy code continues to play an important role in many organizations’ environments, and security teams need to scan this code and prioritize the most important fixes. Older code is less exciting than shiny new application code, so fewer people are interested in working with it, but it still requires careful consideration pertaining to security.

4. The newest security tools are often not licensed to deal with legacy code. Problems build up over time if the code isn’t maintained and secured.

Third-party and open source vulnerabilities

The widespread use of third-party and open source libraries makes them an attractive attack vector. Transitive (or indirect) dependencies are a particular concern since developers may be using vulnerable packages without realizing it.

This issue was highlighted recently when Snyk uncovered an instance of sabotage by the maintainer of the popular node-ipc package. The maintainer added a module called peacenotwar which detects a system's geo-location and outputs a heart symbol for users in Russia and Belarus. peacenotwar had virtually no downloads until it was added as a dependency to the node-ipc package.

This incident, together with the similar intentional corruption of the npm package colors, shows that external attackers aren’t the only concern with open source dependencies. Maintainers themselves could be releasing packages with malicious code or vulnerabilities.

It’s impossible to catch all these vulnerabilities manually, so to secure open source dependencies, you need tools that can make you aware of what to update (and when) and detect new vulnerabilities as they arise. In addition to scanning tools, policy enforcement can help build security into projects from the start. Teams should develop policies that follow best practices, and select tools that enforce those policies. The OpenSSF framework, for instance, sets rules for open source software projects to comply with. If everyone used this framework then security tools might not be as necessary, but this is unlikely to happen anytime soon.

Adopting a DevSecOps approach

In addition to security tools, it’s critical to take a shift left approach and incorporate security throughout the development process. Traditionally, scanning has taken place late in the software development life cycle. The results would be sent back to development teams for fixes, which meant security teams became a bottleneck for other areas of the business. The tooling itself compounded this bottleneck with additional headaches for developers: The high number of false positives meant team members lost time triaging issues.

This legacy approach worked sufficiently well for organizations using a waterfall approach to software releases, but modern software development requires a tighter, more agile integration between security and development. Finding and fixing issues earlier in development makes the process more efficient for security teams and everyone else involved.

Shift left testing integrates testing best-practices as early as possible in the CI/CD pipeline.

Shift left testing integrates testing best practices as early as possible in the CI/CD pipeline.

Finding qualified experts

In addition to shifting left, the human side of security is important. Finding qualified security experts is a top priority, and security teams themselves need to improve their training, develop efficient processes, and analyze their tooling. They can then equip themselves for a more integrated security approach, where scans happen in parallel with CI/CD pipelines so developers can easily apply fixes. Organizations are finding it difficult to hire experienced cybersecurity staff, as the ratio of developers to security practitioners is around 100:1, so more organizations are leaning more on developer security with education and automation.

Lack of a centralized management tool

Security professionals are tasked with managing the risk that an organization is willing to expose itself to. The idea that it’s possible to reduce this risk to zero is in the best case naive, and in the worst counterproductive. A major aspect of risk management is to assess the vulnerabilities the applications contain, and to prioritize which one to address, when, and how.

Application security teams need tools to support them. They need to constantly monitor and assess the security posture of an application. Security posture means the combination of security knowledge at all levels of the application. Based on this knowledge, security teams need to triage and build a backlog of issues to address as part of the application security process.

Finally, the security team needs to monitor and ensure that issues from the backlog are correctly and timely addressed. The best tools will be able to centralize all of this necessary reporting, and present it to stakeholders in a single dashboard.

OWASP Top 10 Application Security 2021: Highlights

The OWASP Top 10 2021 gives a diverse list of vulnerabilities that serves as a baseline for evaluating tools. Here are two important points to note:

1. The list changed significantly from the previous year due to changes in threat profiles and a new list-building method that considers both the exploitability and the potential impact of a vulnerability. Broken access control moved from #5 to #1, while identification and authentication failures dropped from #2 to #7, perhaps a result of standardized frameworks becoming available.

2. The vulnerabilities come in a wide variety, from insecure design to cryptographic failures and failure to verify data or pipeline integrity. This means that security not only needs to shift left —- it needs to cover every aspect of an application.

The OWASP Top 10 2021 is based on data from over 500,000 applications so it provides valuable insights into common vulnerabilities and their risk profile. As such, it is a good starting point for evaluating how comprehensive a given tool is.

In the 2021 version, the top risk is broken access control, an issue Snyk Infrastructure as Code (Snyk IaC) addresses. The third is injection attacks, which Snyk Code can unveil using data flow analysis. Number six on the list is vulnerable and outdated components, which can be found by Snyk Open Source.

In summary, Snyk addresses all elements of the OWASP Top 10 that application security testing can assess. Learn more about the OWASP Top 10 and read the full list with our analysis.

The three tiers of application security architecture

There are three tiers in the architecture of a modern application. Each tier has its own risks that need to be addressed. Here’s a look at each one, its makeup, and its potential risk profile.

The top tier: clients

This top tier, which may be a web front end, internet of things (IoT) front end, or mobile front end, is where users interact with an application. Front end developers prioritize providing a high-performance, high-quality experience to the end user, but each type of front end has its own threat profile, so security should not be overlooked. There are numerous ways to attack the front end, including injection and denial of service attacks.

The middle tier: the application

This is where data collected from users is processed. The tiered architecture itself helps protect against exploits by creating a kind of firewall between end users and data. Other tools like fine-tuned access controls can help secure this middle tier.

The bottom tier: the back end

This includes operating systems, cloud infrastructure, containers — everything used to run applications and store data. The goal of most attacks is to breach this tier, so it’s important to use secure configurations, properly configured networks, and robust data encryption to secure the back end.

A diagram of the architecture of a modern application

In the below diagram we see the architecture of a modern application. Powering the front end is a business logic and data layer that exposes an API to the front end and runs inside of the cloud (such as AWS, Azure, or Google Cloud).

On the left side, source code defines the client and logic, packages for your dependencies, cloud specifications (using IaC), and container files that give the configuration of containers your application will run in.

On the right side is the active production management. The cloud management consoles for production are especially valuable targets for hackers: if someone gains control of your cloud management console, they can use it to take control of machines to mine bitcoins, among other unauthorized uses.

Application security architecture diagram

It’s important to orchestrate security across the tiers to ensure it can be managed and operationalized. Doing so can have additional side benefits such as the ability to detect click fraud, which can cause cloud oversubscription.

3 Key pillars of application security

There are three primary pillars of effective application security:

• Technology, including process and training tools

• Processes, including policies, principles, and controls

• People, who require education and training about security (such as to prevent phishing)

It’s necessary to triage the importance of each section for your business so you can evaluate your weak spots and determine where you can improve. Furthermore, these pillars interact. For example, all tools have human elements. A tool is only as good as the people trained to use it. Humans in turn can think strategically about tools, such as by using physical security as well as software security. Check out our 15 point checklist for application security best practices for more detailed steps.

Here are some best practices around the three pillars of application security:

Technology: review your toolset

1. Start by defining a comprehensive set of tools that can integrate with each other and that fit with your resource capabilities and budget. Remember that the best tools give recommendations — they require humans to action those recommendations to show the most value.

2. Explore the new tools that are available and review their capabilities.

3. Plan your tools roadmap. Where are they going? What is your vision around tooling? Will those tools keep up with your business needs?

Process: be clear

1. Start by defining your application security processes. Write them down to help gain clarity.

2. Test your processes. Do they actually work? It’s better to learn about any issues during testing rather than during an emergency.

3. Maintain a process repository. Keep your processes in one place. This helps during onboarding and can help you spot overlaps in processes.

Humans: embrace their role

1. Security teams and developers are knowledge workers. They need to be “upgraded” much like how software itself requires upgrades. The security field is constantly changing, but the development community is rich with information, training, and events. Educate and invest in your people so they know how threats and mitigation practices are evolving.

2. Invest in all layers of security. Everyone should be made aware of the importance and rules around security, from cleaners to CEOs.

3. Encourage an open culture for the smallest things. “SEE IT, SAY IT, SORT IT” should be the motto. An issue can’t be fixed if nobody mentions it.

Six types of application security scanning tools

Scanning tools are central to application security because they allow developers to test applications before running them in a production environment. These tools come in many different forms, including ones that scan source code directly and others that evaluate an application by running inputs through it. Here are six common types of scanning tools:

• Static application security testing (SAST): SAST is a white-box testing method with access to source code, at rest, it identifies weaknesses that may lead to a vulnerability and then generates a report.

• Interactive application security testing (IAST): This form of application security testing scans the source code for vulnerabilities while running the application and simulates the ways a user would commonly interact with it.

• Software composition analysis (SCA): Also known as origin analysis, this method helps to analyze all sourced software components and libraries. These tools help identify known vulnerabilities and notify the user of any available patches or updates.

• Dynamic application security testing (DAST): DAST tests an application’s security posture by applying different attack types to the running application. It does not require access to the application’s source code, making it a black box testing method.

• Application security testing as a service (ASTaaS): In this scenario, the organization enlists an external company to perform all testing for their applications. ASTaaS usually combines static and dynamic security methods, including penetration testing and evaluating application programming interfaces (APIs).

• Fuzzing: Fuzzing tests an application by inputting randomized data to uncover potential bugs. Fuzzing compliments IAST, DAST, SAST, and other forms of testing.

SAST vs DAST vs SCA

How Snyk helps with application security

Snyk is an essential application security technology because it provides end-to-end monitoring and mitigation steps that integrate into developers' existing workflows. Its tools include:

1. Snyk Code: A developer-first SAST tool aimed at making fixes easy and efficient;

2. Snyk Open Source: A software composition analysis (SCA) tool that uncovers and prioritizes open source vulnerabilities;

3. Snyk Container: A tool that helps secure containers from base image to runtime;

4. Snyk IaC: A tool that helps developers write secure IaC configurations.

5. Snyk Cloud: A tool to help developers manage their cloud security using Policy as Code.

Here’s a visual display of how Snyk’s toolkit fits into application security:

Snyk’s tools are the natural next step towards automating developer security as much as possible. It’s continuing its evolution towards securing applications at runtime with its partnership with Sysdig and its recent Fugue acquisition. Together these tools help developers ensure application security throughout the application life cycle.

Application Security Examples

Check out our case studies for examples of organizations that have used Snyk to improve their application security process and posture with developer-friendly workflows.

"The Glovo security team has reported a 78% reduction in critical vulnerabilities in its dependencies and code using Snyk. Furthermore, the team has achieved a 40% reduction in their mean time to fix, demonstrating overall that they’re able to ship more secure code faster."
Glovo

Suggested Reading

15 Application Security Best Practices 2022 | Snyk

What is an application vulnerability? | Snyk

Top 10 application security acronyms | Snyk

Frequently Asked Questions