What is application security?

Application security is the combination of tools, practices, and policies that are used to protect the application layer of software from threat actors. Once something of an afterthought, application security is now widely and rightfully recognized as a vital part of the software development life cycle (SDLC). As the complexity of technology increases, considering application security early and often in the SDLC is imperative to keeping data and resources from falling into the wrong hands.

This straightforward guide will help you build a better understanding of application security and the tools and practices your organization can use to stay protected. 

Why is application security important?

Globally, the average cost of a data breach in 2023 was over 4 million. For US companies, that number was over 9 million, according to IBM.  The Verizon 2024 Data Breach Investigations Report found that web applications are the top hacking vector in breaches. The cost of ignoring application security is high.

Beyond the painful enough money loss, the good reputation of a business that took years to build up can crash in the blink of an eye after a serious security failure. In 2017, Equifax suffered one of the worst data breaches in history. The following year, after compiling financial data and several customer surveys, USA Today declared Equifax “The Most Hated Company in America” Ouch.

Virtually all businesses, not just those in tech, now use software to run their daily operations, ultimately meaning that application security, or a lack thereof, affects nearly every human on the planet.

The major challenges of AppSec

Protecting applications isn’t for the weak. Here are some of the major challenges to keeping apps safe today.

App + Sec relationship status: It’s complicated

A vast, sprawling, and complex landscape filled with vulnerabilities at nearly every twist and turn, the application layer is the top infiltration spot for bad actors in search of valuable data and other assets. The increasing complexity of applications and the systems and architectures they connect to makes securing them properly a real technical challenge.

Third party woe

Modern software is rarely built entirely from scratch. Rather, modern software is composed, often by about 80% existing open source and third-party code and 20% custom code to bind it all together and add a layer of innovation. Open source code by definition is freely available to examine and is used by many people, making it an extremely inviting vector for bad actors. Code from a vendor may be more obscured but as the SolarWinds hack showed us, can still provide a major attack surface.

Who, me?

A frequent challenge to application security lies in intra-organizational confusion about who exactly is responsible for it. This ends up with a lot of pointed fingers and not a lot of positive action. Unsurprisingly, the answer to who is responsible is “everyone” but that really must start with the people controlling the budgets.  Taking security seriously starts with funding the tools needed to do a good job.  

Deep in technical debt

We all love our old software, still functioning and bringing in money, but aging software is especially prone to accruing large amounts of technical debt, which leaves applications insecure. Shortcuts made to keep up with shrinking software release cycles are another source of technical debt and security weaknesses. Finding the time and will to pay down the debt can be a struggle for many organizations.

Application security best practices

From how you organize your company to how you write a single line of code, there are many ways to practice great application security. The application security best practices here are just a few high-level suggestions to get you going.

Work together

Not to be cliche, but teamwork really does make the dream work. If application security is not already a part of your organization’s culture, here are some things you can do to get started.

Bring down the firewalls between development and security teams

Name one or more members of your development team as security champions. Security champions are active members of a development team that serve as security ambassadors within their team. Security champions also provide visibility of their team’s security activities to the application security team, and often  the point person between developers and a central security team.

Incentivize developers to use security tools

As a group, devs may not be particularly well known for their people skills, but they do know something about human nature: people don’t like to do things that are repetitive or tedious. In software engineering laziness is a virtue, so meet developers where they are and give them tools to work smarter and minimize busywork–tools that are embedded right into the work environments they’re already using and coding within.

Manage privileges

For all the silos you should knock down to integrate your team into a lean, mean DevSecOps machine, you should be bringing up walls when it comes to user privileges. Make sure that users across your organization are restricted to only having access to the data they absolutely need, so you can reduce your attack surface from security concerns from both within and outside your organization.

Know your stuff

It’s difficult to protect something that you aren’t aware you have, and it’s also not so easy to convince people you’re doing something if you aren’t even sure yourself. It’s time to clear the fog. 

Track assets

Tracking your assets simply means knowing which hardware and software you’re using and what they’re doing.  

While you’re taking stock, it’s a good idea to note and prioritize those things that:

• Access vulnerable networks (like the public internet)
• Access personally identifiable information (PII)
• Access financial information
• Are subject to regulation
• Are public facing
• Are crucial to business function

You should have a record of all of the code, open source and custom, that your products depend on, all of that code’s dependencies, and all of those dependencies’ dependencies, and… you get the idea. Another great reason to create and keep updated SBOMs.

Model threats

Malicious actors care about what you care about. Now that you have a good idea of what’s important, you can start looking for ways they might try to get it for themselves.

If you’ve never threat modeled an application before, here are the basic steps:

1. Document how the application functions, focusing on the flow of data through the application.
2. Find threats against the application by following the flow of data and identifying places weak to certain exploits (attack databases work well here).
3. Address threats by rating them and deciding on mitigation strategies.
4. Validate the model to make sure you didn’t miss anything.

Define your metrics—know your risk, track your efforts

Quantifying and tracking security isn’t always a straightforward task, especially when the best security is done before there’s even a problem. But having good numbers for your efforts, results, and risk profile is essential to making good decisions and justifying your work. Which metrics to track and how to track them are very organization-dependent, but consider measuring:

• Risk. Use this basic formula: Risk = Probability of attack X impact of attack
• Time spent on education and estimated number of issues prevented
• Percentage of process made to be automated over time
• Number of issues kicked back to developers
• Average time for developers to fix an issue

Shift left, shift everywhere, shift smart

Sometimes even agile organizations find themselves administering security to the tempo of an old school waterfall pipeline—a software idea is born, a team of developers writes it into being, and then the big bad security team finds numerous flaws that need to be addressed by the devs before release, causing a major break in flow and a bottleneck in the SDLC. There is a better way.

Shift left – design with security in mind

The rumors are true: the beginning is in fact a very good place to start. “Shift left security” means moving security considerations as early into the SDLC as possible and that should mean right into the very design and conceptualization of a product. One way to achieve this is to define your security policies right from the start to set consistent boundaries and create efficient development processes.

Shift everywhere – make security a part of every stage of development

But wait there’s more! There are many spots in the SDLC where security can and should move left. Bringing security testing into the early development stage, as code is created, is preventive care that immediately translates to time and money saved. But don’t stop there. Use your security champions to ensure that security concerns are addressed regularly throughout development processes.

Shift smart – automate security and minimize false positives

Done correctly, shifting security up, down, and all around shouldn’t slow production. Add a dash of automation, and you might even find development speeding up. Tools are really the driving force behind shifting smart. Find the right tools that automate security and give developers just-in-time feedback that allows them to remediate security concerns without requiring them to become security experts themselves.

Application security assessment

It is important to perform an application security assessment in order to evaluate and understand your true risk and to create a plan for addressing security issues. A full application security assessment includes identifying sensitive data, threat modeling, mapping out your applications to identify which areas will need which types of security tools, searching out gaps in your security process, and creating a security roadmap.

Vulnerability assessment

A vulnerability assessment is a systematic review process that uses vulnerability scanning to identify areas of an application that potentially need security improvements. This differs from penetration tests, which are usually more limited in scope but identify real and exploitable application vulnerabilities.

Popular resources for application security

Be comforted by the fact that you are not alone. A large number of individuals, teams, and organizations have dedicated their time and experience to bringing application security to all. Here we highlight some fantastic (and free) resources.

MITRE’s CWE Most Dangerous Software Weaknesses 

Using real-world data from the U.S. National Vulnerability Database and combining frequency and severity to determine rank order, every year this community-developed project puts out a list of the top 25 hottest, most on-trend software weaknesses.

OWASP Top 10 

Open Web Application Security Project (OWASP) puts out their own list that is unsurprisingly focused on web application security. It is well worth a gander as it particularly comprises low-hanging fruit that hackers love to bite.

The Linux Foundation

A hub of open-source activity, The Linux Foundation’s website is a wealth of resources including guides, webinars, research papers, and free courses.

OpenSSF

One of The Linux Foundation’s many projects, Open Source Security Foundation (OpenSSF) offers free training and certifications, guides, reports, and a robust community of security buffs.

MITRE ATT&CK Framework 

A major resource for threat modeling and beyond, MITRE’s Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK) is a knowledge base and playbook of offensive moves and the defensive actions necessary to combat them.

Cybersecurity Framework from NIST

If you like comprehensive security frameworks, this one’s for you. Designed with the security of critical U.S. infrastructure in mind (and likely to become mandatory for some sectors), the Cybersecurity Framework from NIST is a well-organized body of standards, guidelines, and practices that can help any kind of organization stay secure. It is helpfully available in 10 different languages.

Some important application security tools

Perhaps someday there will be one tool to rule them all and cover the entire software supply chain, but as it stands, staying secure typically requires multiple application security scanning tools to get the job done well. As code changes throughout the SDLC, so do the tools needed to keep it secure. Here are a few stand-out tools to protect both your custom code and the third-party and open source code that makes up your software supply chain.

Application security testing

Application security testing is a market category that includes both security scanning tools and runtime protection and monitoring tools. Software composition analysis (SCA) is also part of this category but we’ve put it into a different section with other tools concerned with open source software.

Security scanning tools

• Static application security testing (SAST) – Implemented at the coding and testing stages of development, SAST tools analyze custom application source code from the inside out (“white-box” testing) and look for coding and design issues that may indicate security vulnerabilities, including old favorites like SQL injection, input validation, and stack buffer overflows. Because SAST tools are deployed at the development stage, before applications go live, the issues they find tend to be cheaper and easier to locate and fix than issues found later in applications that are already running.
• Dynamic application security testing (DAST) – A complement to SAST, DAST takes the opposite approach and tests running code for security vulnerabilities without any visibility into the source code (“black-box” testing). DAST is usually limited to testing only the exposed HTTP and HTML interfaces of web-enabled applications and takes a hacker’s rather than a developer’s perspective.
• Interactive application security testing (IAST) – IAST is designed to complement SAST and DAST. Like DAST, IAST is deployed in a QA or testing environment to test running code. Unlike DAST, IAST has knowledge of the post-build code and can identify the line of problem code and notify a developer for immediate remediation. IAST is not without its own limitations, however, as it does not scan the entire codebase, and coverage across all languages and platforms is still lacking. 

Application security monitoring tools

• Runtime protection tools are used in production and designed to defend against threat actors in real time. This market is segmented into web application firewalls (WAF), bot management, and runtime application self-protection (RASP).

Open source software security

Keeping open source software secure typically involves keeping components cataloged and up to date. Here are a few tools that help you do that.

Software composition analysis (SCA) – SCA tools manage the use of open source components by performing automated scans of an application’s code base (and related artifacts, including containers and registries) to identify all open source components, their license compliance data, and any known security vulnerabilities. Many SCA tools also detect malicious packages and enforce an organization’s policies on bringing new open source components into projects.

Automated dependency update tools – Automated dependency update tools scan repositories for open source dependency information, check for updates, then create pull requests for the latest versions.  

Cloud-native application security

Cloud-native applications have a lot of advantages in terms of scalability but they introduce a few unique security issues that new cloud- and container-specific security tools address.

Container image scanning – Container image scanners are similar to SCA scans applied to container image layers but with some container-specific twists. In addition to scanning for and reporting vulnerabilities at each image layer, they scan for misplaced secrets and configuration issues.

Cloud-native application protection platforms (CNAPP) – CNAPP consolidates a number of cloud security services into a single platform including container scanning, cloud workload protection, and runtime vulnerability and configuration scanning.

Trends in application security

Worldwide government interest in AppSec

World governments and legislatures across the globe have taken a strong interest in cybersecurity, particularly application security, in recent years. The Biden Administration’s 2023 Cybersecurity Strategy shows that the United States government is pushing for regulatory mandates relating to software used in critical infrastructure and the European Union, Australia, and many other governments have announced similar goals for cybersecurity. Meaningful progression security compliance may start with government contracts but it won’t end there. Civilian business consumers of software are also starting to demand more secure applications and transparency into what their vendors are doing to keep code safe.

Increased adoption of SBOMs

One way for vendors to provide that transparency is in the use of Software Bills of Material (SBOMs), machine-readable logs  that account for all software components, their dependencies, and their relationships. SBOMs take their name and function from traditional industries like automobile manufacturing where makers keep records of information about all of the parts in a machine. Should one of those parts get recalled, these manufacturers know which vehicles to call back to the dealership for repairs. So it goes with SBOMs. By keeping an up-to-date record on hand to be provided by regulators when requested, software companies are kept responsible for their products. Needless to say, governments are pretty excited about it, but companies should be, too. SBOMs are invaluable instruments for tracking a large breadth of code and finding vulnerabilities even before the authorities come knocking.

Automation becomes essential

Across the globe, the number of jobs for security professionals continues to rise quickly, while the supply of people to fill these jobs continues to lag. This leaves organizations with little choice but to train their developers in security and automate as much as possible. But even if your organization had a budget big enough to snag all the top cybersecurity talent in the world, modern software is so complex and is deployed so quickly that trying to address application security without automation is nearly impossible and definitely unrealistic.

Application security forecast

Finger to the wind, here’s what we think may be coming down the pipeline soon.

Increased demand for suppliers to not just provide SBOMs but list known vulnerabilities

With great maturity comes great responsibility. As the software industry matures, the expectation that vendors are responsible about securing their products increases. In the past, software customers often didn’t have security on the front of their mind, but things are changing. Expect to be asked not just for SBOMs but a list of known vulnerabilities in the near future.

FDA-type bodies to regulate software concerning critical infrastructure

Application security concerns don’t go away if one political party or another is in charge. World governments have stated their seriousness about cybersecurity in the last few years, but so far most of their statements remain only recommendations. We think an increase of hard regulation and the formation of regulatory bodies to monitor compliance is on the horizon.

Increased use of artificial intelligence and machine learning

AI and ML both hold great promise. Unfortunately that’s for the bad guys, too. As developers lean on more AI-written code, scanning for security concerns will become more crucial than ever. New issues beyond anyone’s comprehension a few years ago are sure to soon arise such as “hallucination squatting” where crafty malicious actors take advantage of AI’s tendency to hallucinate (i.e. make up) credible sounding sources of information like the names of open source repositories. On a happier note, the integration of machine learning into security tools will soon make triaging issues even better.

How Mend.io can help

The Mend Application Security Platform provides comprehensive security solutions for your entire codebase.

Mend SAST allows your developers to rapidly design new applications while maintaining the security of their custom code. With Mend SAST integrated right into your favorite DevOps environment and continuous integration/continuous development (CI/CD) pipelines, developers can easily evaluate the recommended code changes and approve them using a simple pull request.

Mend SCA detects open source vulnerabilities in over 200 languages, frameworks, and development tools. Like Mend SAST, it provides pull requests with automated remediation, enabling developers to update the recommended open source package with just a single click. Mend SCA also enables the easy creation of SBOMs.

Mend Renovate automatically resolves outdated dependencies saving time, reducing risk, and mitigating the impact of security vulnerabilities.

Mend Container gives you agentless reachability analysis for container vulnerabilities as well as secrets detection and Kubernetes cluster scanning to help make vulnerability prioritization simple.

Mend AI catalogs the AI models in your codebase and keeps track of their licenses, versions, and security alerts.

FAQ

*** This is a Security Bloggers Network syndicated blog from Mend authored by Adam Murray. Read the original post at: https://www.mend.io/blog/application-security/