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.

• Global average cost of a data breach:  > $4 million
• U.S. companies: > $9 million
• Top attack vector: Web applications

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.

Find out more about the Mend AppSec Platform

A single platform that supports both developer and security teams

See the platform

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

And something has gone wrong with it.

On February 15th of this year, the NVD posted a notice to the top of its site stating:

“NIST is currently working to establish a consortium to address challenges in the NVD program and develop improved tools and methods. You will temporarily see delays in analysis efforts during this transition. We apologize for the inconvenience and ask for your patience as we work to improve the NVD program.”

This didn’t garner much attention at the time but as the weeks passed, analysts began to realize that the NVD was becoming seriously behind with fully reporting CVEs.

Before we get into what that means, let’s take a quick step back and review how a CVE becomes an NVD CVE. Schoolhouse Rock wasn’t available to make a song about it, but I’ll try to keep it quick.

You down with NVD? (Yeah CVEs!)*

CVE stands for “Common Vulnerabilities and Exposures”, which is a framework developed by MITRE, but most people use “CVE” as a singular noun and faster way to say “known security flaw that’s already been assigned a CVE ID”. 

CVE IDs are reported by CVE Numbering Authorities, also known as CNAs, also known as about 350 large tech companies, security vendors (Mend.io is one), and researchers. Other people and organizations find vulnerabilities, too, but one way or another they find their way to CNAs who actually report them so they can become bonafide CVEs. 

To recap the alphabet soup: A CNA reports a CVE; and it then gets a CVE ID and enters the NVD.

On its own, a CVE gives very little information. It gives a little bit of the what, but not the what kind, where, or the how bad. Right away, when a CVE becomes public, the NVD adds it to the site, but it’s not finished cooking yet. To be an official NVD CVE, it needs to be a fully tagged, meaning it needs to be mapped with a bunch of other cybersecurity acronyms, namely:

Common Weakness Enumerators (CWEs) – Another MITRE classic, CWEs describe the type of coding or architecture flaws that underlie a vulnerability. There are about 600 of them and they’re not all strictly about security issues.

Common Vulnerability Scoring System (CVSS) – A CVSS score describes the impact severity of the CVE. We have written about this before, but it should be noted again that a base CVSS score is more of a worst-case scenario, not a declaration that everyone using software with a CVE is equally affected.

Common Platform Enumerator (CPE) – CPEs are just systems, software, and packages. It’s kind of important to know what thing you have to be using to be in danger of a CVE. More on that in a minute.

If you didn’t want a refresh, you can start reading again here

So now that we know that an NVD CVE is supposed to include CWE (what kind of problem), CPE (which thing in your stack), and CVSS (how bad it is), it becomes a little concerning to learn that for the past month, the NVD hasn’t been tagging those things. In fact, since mid-February, thousands of CVEs have been left untagged. 

The NVD has only tagged a measly 59 CVEs since February, leaving a full 40% of 2024 CVEs without vital information.

Not tagging CPE is a really big deal, as it’s the main way to match a CVE to one of those components, and is relied on by many home-grown vulnerability solutions (but not Mend SCA!). So no CPE means those solutions won’t know to match a vulnerability with a library -– it just won’t show up.

What exactly is happening over at NIST/NVD to cause this huge backlog is anyone’s guess. No one has made any statement, officially or otherwise.

Oh no! Am I affected?

Quite a few SCA solutions use the NVD as a sole or at least primary source of vulnerability information and if this is yours, then the lack of CPE data especially may be leading your SCA to fail to report CVEs that you are very much affected by. False positives are the usual SCA problem but here we’ve got a false negative problem. 2024 is shaping up to be a crazy year!

By the way, Mend SCA is not one of those SCAs. We source our information from many places, and we’ve ensured that we’ve covered what NVD is lacking. If you’re a Mend SCA customer, you don’t have to worry about this.

If you’re using Mend Renovate and keeping your dependencies healthy and up to date, you’re also all good. After all, updating to a later version is the recommended way to address most CVEs — so if you’re up-to-date, you don’t have to worry about the severity of a vulnerability you don’t have.

*My deepest sympathy to anyone who did not get to enjoy the 1990s/musical stylings of Naughty by Nature.

What is EPSS and what does an EPSS score tell me?

The Exploit Prediction Scoring System (EPSS) is powered by volunteers from the public and private sector and is under the management of a security non-profit organization known as Forum of Incident Response and Security Teams (FIRST). EPSS is designed as a new approach to prioritizing vulnerability remediation. Designed for use as pre-threat intel, an EPSS score uses both CVE data and real-world exploit data to generate a percentage that represents “a daily estimate of the probability of exploitation activity being observed over the next 30 days”. The EPSS model makes use of over a thousand variables and machine learning to fine tune its predictive powers. While FIRST maintains a special interest group (SIG) for EPSS that is open to the public, the actual special sauce of producing an EPSS score is not publicly available.

EPSS and public exploits

Many common vulnerabilities and exposures (CVEs) are concerning but theoretical. When there’s a real and known way of exploiting a CVE in the wild, you’ve got yourself a public exploit. Even a rather low severity CVE becomes a very high-priority threat when it has an exploit. Exploits range in maturity from proof-of-concept, such as an academic releasing a paper on how an exploit could be performed, all the way to high severity, where the exploits are already packaged as tools that are readily available to script kiddies.

An EPSS score predicts the likelihood of a vulnerability going from theoretical to having a public exploit in the near future, so you’d expect a vulnerability that already has an exploit to have an EPSS score of 100% but the EPSS model doesn’t actually take into account if a public exploit already exists. The reasoning behind this is that just because a CVE has one known exploit, doesn’t mean more can’t be created.

What is the difference between CVSS and EPSS?

The Common Vulnerability Scoring System is a free and open standard for scoring the severity of a vulnerability based on multiple factors, one of which is its current state of exploitability, as in whether or not there is currently an exploit or exploits and the maturity of said exploit(s). FIRST is also the steward of CVSS, but the teams working on the scoring systems as well as the SIGs for each initiative are separate. CVSS scores do get updated, such as when new exploits are found, but they don’t attempt to predict the future like EPSS scores do. A couple of other key differences:

Usage. CVSS calculators exist for you to determine the severity of any vulnerability, including those that are not yet publicly disclosed, whereas the models behind EPSS are closed source and thus EPSS scores are published only by FIRST and are presently only available for CVEs with IDs. 

Complexity. Another difference is that the EPSS model is more complex and updated more frequently. Compared to EPSS, CVSS is a far more static and simple system, having just released its fourth version in its 18th year of existence, whereas EPSS is already on its third version and is only just coming up to its third birthday.

The creators of EPSS argue that the common security strategy of fixing vulnerabilities with a CVSS score of X or above (in their demonstration they use a threshold of 7 and above severity for CVSS and 10% and above for EPSS) results in a high amount of wasted effort as most of those vulnerabilities will not end up being exploited. 

The benefit of prioritizing vulnerability remediation based on EPSS instead of CVSS is a reduced amount of effort and increased efficiency due to the large reduction of false positives. The cost is an increase in false negatives (in their demonstration, the number doubles). However, it should be noted that false negatives are very low to begin with, especially compared to the false positives of this strategy.

It is also worth noting that the documentation on EPSS compares its current version with CVSS 3.0. CVSS 4.0 has just been released and it does a better job of weighing temporal and environmental data (like exploitability and application context) in the final score, which means most CVEs will have lower scores under CVSS 4.0 than they did under CVSS 3.0.

The limitations of EPSS and some practical advice

EPSS scores can’t be the be-all and end-all of prioritization metrics. As mentioned above, EPSS scores are only available for those CVEs that have IDs. Vulnerabilities that don’t have IDs, like misconfigurations and zero days, are also important to look out for.

Your prioritization flow should begin with asking if there already is an exploit. If there is, then it should be prioritized, and the EPSS score isn’t particularly relevant.

Confidence levels are not given separately but are baked into the EPSS score and the higher the EPSS score, the higher the confidence. This means that lower EPSS scores should be read along the lines of “we don’t know” rather than “not an active threat”. On the other hand, CVEs with high EPSS scores should be treated as if there is already a public exploit, because there’s a very good chance there will be.

Those with very low risk tolerance and the budget to back it up should continue to rely on prioritizing via CVSS. Conversely, those with limited resources and more risk tolerance may benefit from prioritizing via EPSS. Those in the middle can leverage a strategy that uses both. Many software composition analysis (SCA) vendors provide proprietary prioritization scores that weigh CVSS and EPSS (and other elements). If you plan to do your own weighing, a comfortable threshold for either or both metrics will need to be established based on your organization’s needs.

One extra bonus use of EPSS: even if your organization chooses not to rely on EPSS for prioritization, EPSS scores, unlike CVSS scores, can be combined and then utilized to measure and compare your security posture over time.

In fact, according to a recent research report Mend.io commissioned from TechTarget’s Enterprise Strategy Group, building such relationships improves application security. The report shows that organizations with the ability to efficiently remediate vulnerabilities were much more likely to strongly agree that they encourage collaboration between application development, security, and operations to build a culture of security. These respondents were also much more likely to strongly disagree that their development teams view security as a hindrance and that their security team believes their development teams subvert security policies to increase development speed. 

The takeaway is clear: organizations that have strong and healthy relationships and collaboration between their teams have better security. Here are four key tactics that will help build that important culture of security.

Start from the top

It’s likely that your security team is much smaller than your development team, so they could do with a little back up. Make sure that security is a board-level concern and that all of your top execs and managers are taking it seriously. Buy-in from the top goes all the way down the company and primes developers to listen to your security team.

While it may be true that in the long run developers end up with the most hours of security training, Chris Lindsey, Global Director of Professional Services at Mend.io, says it’s the top level that needs security education the most. Lindsey, who has overseen many successful security initiatives, recommends that at the initial push you give executives five days of training, leads and managers four days of training, and typical developers three days of training. 

Know thy friend

Create and promote opportunities for security and development staff to know each other as people. Depending on the size and configuration of your organization, seating them physically nearby may not be feasible but there are other options. 

Have at least one person from the security team sitting in on all of the development teams’ weekly meetings. Doing this serves multiple purposes: it makes your security team’s faces more recognizable, it gives developers an opportunity to ask questions about securing what they’re working on right now, and it gives your security team an understanding of what developers are doing and what they need.

Coordinate with the team leads to allow room for some informal chit chat to occur within the meetings to help developers and security staff get to know one another and build work friendships. Remote teams can do this by guiding the first ten or so minutes of weekly calls to be open discussions about how life is going, what did you all do over the weekend, etc.

Listen

The security team is often asking developers to squeeze more things into their processes when they’re already feeling pressed for time. Giving developers a chance to voice their concerns and see that their needs are taken into account goes a long way in gaining their trust and cooperation.

When you create security policies, do it out in the open and actively encourage and leave time for feedback from anyone in the organization. It’s much easier to enforce a policy that has already been formed and agreed upon by all stakeholders.

Promote empathy and be humble

In some organizations, developers come to see the security team as grumps who only come around to bark at them about theoretical issues. Don’t let this happen to yours.

When you or your security staff need to run meetings with developers, be firm about security policy but stay generally light and supportive. As you discuss security concerns and vulnerabilities, make sure to share stories and make it real, rather than rattling off a list of directives.

No tool is perfect and false positives do happen. When your security team is wrong about something, encourage them to build trust with developers by having the grace to admit their mistakes. Let your developers know that your security team never intends to waste their time, and conversely, make sure your security team knows that developers never intend to code insecurely. Everyone wants to do a good job.

Culture is always about people and security culture is no different. Building trust and great relationships between security and development is worth the time and effort. This quote from Derek Samford, Senior Director of Security at Avalara, sums it all up beautifully: “I really don’t think the need for empathy in security roles is talked about enough. The simple truth is that when people feel like you’re on their side, they do better work. When people feel like you’re out to get them, they become less transparent and prone to hide things from the security team.”

Why is the OWASP API Security Top Ten important?

The API Security Top Ten focuses on application-programming interfaces (APIs), the bits of software that let two or more separate computer programs communicate and exchange information with each other. It sets out the categories of common flaws and weaknesses in APIs, particularly web-based APIs that communicate across the internet rather than through a closed network. It provides developers and security teams with an up-to-date guide to the most common and dangerous mistakes they could encounter that can cause vulnerabilities when building and maintaining web applications. APIs are vital to the development of software functions, and APIs for web applications are frequently sources of security vulnerabilities.

According to the foreword of the 2023 edition of the API Security Top Ten, “APIs are a critical part of modern mobile, SaaS, and web applications and can be found in customer-facing, partner-facing, and internal applications. . . By nature, APIs expose application logic and sensitive data such as personally identifiable information (PII) and because of this, APIs have increasingly become a target for attackers. Without secure APIs, rapid innovation would be impossible.”

As APIs are a significant part of building web applications, reinforcing their security has become increasingly important to maintaining the integrity of organizations’ apps. So, the list is a useful reference for the DevSecOps community to know what to avoid during their builds.

Main findings

The report lists the top ten categories of weaknesses and then drills down into how exploitable, prevalent, detectable, and impactful each weakness is. It provides additional information on how each of these issues may arise, the sorts of problems each may cause, and the extent of its potential damage. It also provides ways to determine if an API might be vulnerable, examples of possible attack scenarios, and suggestions for how to prevent them.

The leading API security issues on the list are authorization and authentication, followed by access issues and unrestricted and unsafe consumption issues. The list identifies the full top ten as follows:

1. Broken object level authorization

Exposure of the endpoints that handle object identifiers, creating a wide attack surface of Object Level Access Control issues.

Exploitability: Easy. Prevalence: Widespread. Detectability: Easy. Impact: Moderate

2. Broken authentication

Authentication mechanisms implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other users’ identities.

Exploitability: Easy. Prevalence: Common. Detectability: Easy. Impact: Severe

3. Broken object property level authorization

Lack of or improper authorization validation at the object property level, leading to information exposure or manipulation by unauthorized parties.

Exploitability: Easy. Prevalence: Common. Detectability: Easy. Impact: Moderate

4. Unrestricted resource consumption

Satisfying API requests requires resources such as network bandwidth, CPU, memory, and storage. Other resources such as emails/SMS/phone calls or biometrics validation are made available by service providers via API integrations. Successful attacks can lead to Denial of Service or an increase in operational costs.

 Exploitability: Easy. Prevalence: Common. Detectability: Easy. Impact: Severe

5. Broken function level authorization

Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. Attackers exploit these issues to gain access to users’ resources and/or administrative functions.

Exploitability: Easy. Prevalence: Common. Detectability: Easy. Impact: Severe

6. Unrestricted access to sensitive business flows

APIs vulnerable to this risk expose a business flow — such as buying a ticket or posting a comment — without compensating for how the functionality could harm the business if used excessively in an automated manner.

Exploitability: Easy. Prevalence: Widespread. Detectability: Average. Impact: Moderate

7. Server-side request forgery

These can occur when an API fetches a remote resource without validating the user-supplied URI. This enables attackers to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall or a VPN.

Exploitability: Easy. Prevalence: Common. Detectability: Easy. Impact: Moderate

8. Security misconfiguration

APIs and the systems supporting them typically contain complex configurations to make the APIs more customizable. Software engineers can miss these configurations, or don’t follow security best practices when it comes to configuration, opening the door for attacks.

Exploitability: Easy. Prevalence: Widespread. Detectability: Easy. Impact: Severe

9. Improper inventory management

APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation, and an inventory of hosts and deployed API versions highly important. Security can be compromised without it.

Exploitability: Easy. Prevalence: Widespread. Detectability: Average. Impact: Moderate

10. Unsafe consumption of APIs

Developers tend to trust data received from third-party APIs more than user input, and so tend to adopt weaker security standards. To compromise APIs, attackers go after integrated third-party services instead of trying to compromise the target API directly.

Exploitability: Easy. Prevalence: Common. Detectability: Average. Impact: Severe

For further details of the main findings, visit the 2023 OWASP API Security Top Ten here.

What does this mean for application security?

APIs are critical to the digital transformation that huge numbers of organizations have undergone in recent years. Nevertheless, when it comes to application security best practices, they are often overlooked even though they are one of the biggest cybersecurity attack vectors. That’s because API security is commonly seen as separate from the overall application security posture of an organization.

APIs are vulnerable because they are exposed to the outside world and a lot of data that passes through the application layer, which makes it attractive to malicious actors. Plus, hacking APIs isn’t particularly difficult, so attackers can easily exploit APIs to perform a variety of damaging actions such as denial of service attacks on critical applications.

APIs are a way for attackers to get into your applications, and seriously disrupt them. Knowing what application risks and vulnerabilities to avoid is key to protecting them and helps you reinforce your application security.  

What is a vulnerability assessment?

A vulnerability assessment is a process of defining, identifying, classifying, and prioritizing vulnerabilities in your organization’s applications, systems, and network for the purpose of understanding your risks and formulating a strategy to improve your security.

At the core of vulnerability assessment is a reliance on automated testing tools that seek out known and potential vulnerabilities and bring them to the attention of security professionals and developers who can investigate and remediate as needed.   

Why is it important?

As recent major attacks like Log4j and SolarWinds have shown, the costs of a vulnerability can be very high. To stay secure, constant vigilance is needed, meaning good security practices require vulnerability assessment to be a repeated process, in some ways even daily, rather than a one and done.    

What are the main types of vulnerability assessments

As noted above, a vulnerability assessment should be carried out for all the elements of an organization’s infrastructure and assets. Attackers know that they have multiple routes of entry into an organization, so it is important to take a comprehensive approach that denies them access across the board. This requires the following types of assessment:

1. Host assessment – Take a hard look at hardware. Are your server, workstation, and laptop operating systems up to date with the latest security patches? Are your servers correctly configured with open ports properly protected with firewalls?
2. Networks and wireless assessment – Reports of the demise of the perimeter have been greatly exaggerated. Are you defining policies and implementing practices that will keep intruders from roaming freely around your network?
3. Database assessment – How we store our data matters. Is it configured correctly to keep prying eyes out? Mistakes in your AWS S3 or MongoDB configs can leave your precious info exposed, so you had better be sure that you are tracking all of your databases and confirming that they are being secured.
4. Application scans – Whether front facing or on the back end, applications are the gateway to your organization’s data, so you should use technologies for testing your proprietary code such as Static Application Security Testing (SAST), while Software Composition Analysis detects open source components with known vulnerabilities.

What is the vulnerability assessment process? How does it work?

The vulnerability assessment process can be broken down into four steps: identifying vulnerabilities, analyzing vulnerabilities, assessing actual risk, and remediation.

1. Identifying vulnerabilities — The first step is to use both manual processes and automated scanning tools to find all of the potential problems you are facing. The outcome of this step is a list of all vulnerabilities.
2. Analyzing vulnerabilities — Now that you have a list, it’s time to dive deeper into each vulnerability. What is the root cause of a particular vulnerability and which components of your infrastructure are responsible for it? This step should leave you with a good map of your systems and what remediation will be necessary.
3. Assessing risk — You can’t realistically fix everything at once. Assessing risk means considering how easily a particular vulnerability could be exploited, how costly an attack would be, and how critical the data, systems, and business functions affected by it are to your organization. Once you have completed this step you will have a prioritized list of vulnerabilities which brings us to…  
4. Remediation — Finally it’s time to go down that prioritized list and close the holes in your security. This step will likely require the efforts of both security and devops teams and may include updates to software, changes to configurations, and the development and implementation of vulnerability patches. 

Five vulnerability assessment misconceptions from the experts at Mend.io

Even if your teams are already running tests for vulnerabilities, they may be falling prey to a number of common misconceptions that can lead to costly mistakes.

We asked our vulnerability experts here at Mend.io about the worst misconceptions that they have seen, so that you can avoid them. 

1. Vulnerabilities are written with malicious intent

Despite the long-held belief among many security professionals, developers do not go out of their way to write vulnerabilities into their code. With very few exceptions, security vulnerabilities are simply bugs and mistakes by developers. Of course, malicious actors don’t care about developers’ intentions; they’re banking on them making mistakes and you not catching them. Cybercriminals may be a minority numerically, but their impact can be huge. It only takes one successful attack like SolarWinds or Log4Shell to cause havoc across multiple organizations.

Application security testing tools seek out these potential errors, flagging them for review before the software makes its way out to deployment.

2. It’s security or DevOps job to handle vulnerability assessments

Back in the day when new software was released once a quarter or so, it was perhaps more reasonable to expect that the security or ops teams alone could carry out vulnerability assessments. Developers just had to care about whether or not the product was working and out on time.

Those days are long gone. The concept of shifting security left has now gained traction and developers have the means to keep code secure themselves, meaning they can integrate automated vulnerability assessment tools into their coding environment to catch vulnerabilities early while they are still easy to fix. However, they need to do it at an unprecedented scale and speed. This can be challenging, when some may lack the familiarity and expertise needed to deal with the remediation of the vulnerabilities.   

3. You can shortcut security

It can be tempting to run a vulnerability assessment only on what you believe to be the most critical servers or layers of your network and call it a day. However, by leaving possible entry points into your environment open, you run the risk of being caught exposed. That said, prioritization does play an important role in planning what vulnerabilities to remediate. Do start with the systems that are the most critical to your business. Then work from there. Just make sure that everything gets some love and attention.

4. Your vulnerability assessment showed up clean, so you’re in the clear 

Sometimes the results of your vulnerability assessment scans will show up cleaner than expected. Take care! You may discover that your data is simply inaccurate. Check and see if it is consistent with past results. More likely is that other vulnerabilities are hidden in the indirect dependencies that you simply can’t see. 

Also remember that your vulnerability assessment only gives you a snapshot of where you stand at a specific point in time. New vulnerabilities emerge all the time, so you need to beware of them. Moreover, changes are always being made to databases or applications as they move through the SDLC.

That’s why you should run security testing continuously along with your assessments, adjusting as needed according to your findings.

5. Running a vulnerability assessment is the same as penetration testing

Vulnerability assessments and pentesting are not the same thing. Instead, they are a part of the same larger process in that the vulnerability assessment is the part that identifies potential weaknesses in your environment, whereas the pentest actually has someone poking around to see what will break.

In short, one step comes after the other, not in place of it. You need them both. An ethical hacker will run a proper vulnerability assessment to generate a to-do list of weaknesses that they should test out. Hopefully, they will use it as a starting point and have their own set of tests that can identify ways to break in, helping your team to remedy situations before someone not on your payroll decides to give it a try for themselves.

Although they complement each other, vulnerability assessment is generally less expensive than pentesting and should be done much more frequently. You can maximize your security spending by identifying and remediating all low hanging fruit through vulnerability assessment, leaving pentesting to take care of business logic flaws that may be missed by automated tools.

Some AppSec vulnerability assessment tools

The application layer is just one of many that need to be considered for your vulnerability assessment, but it’s a big one that takes a lot of effort and care to make secure.

For open source code

Open source code typically accounts for 60 to 90 percent of all code used in modern software products. If all code is equally likely to contain vulnerabilities, your open source components are naturally going to be the source of most of your vulnerabilities. Likewise, nearly all open source licenses require public disclosure that a particular open source component is being used, meaning malicious actors have insight into a large part of your codebase. 

So, performing vulnerability assessments on open source software is vital and the best tool for the job is Software Composition Analysis (SCA). When choosing an SCA, go for one with a low false positive rate and robust open source license tracking like Mend SCA.

For custom code

Even the best developers make mistakes sometimes. Custom code may be a smaller percentage of modern software but it still needs to be checked for vulnerabilities. Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) are two important and complementary tools for vulnerability assessments. SAST uses whitebox testing that integrates more readily into your continuous integration/continuous development (CI/CD) pipeline and can find security vulnerabilities even before code is fully functional. DAST, on the other hand, uses blackbox testing to check already built code for security issues.

For cloud

The SCA tool you pick should support cloud applications just as it does your on-prem code and be able to scan your containers and Docker images and find vulnerabilities in your cloud applications. Another concern for cloud-based application security is dependency management. Cloud applications rely on a lot of microservices which each have many dependencies which can become outdated and missing important security patches. You can easily scan your repositories for outdated packages with a dependency management tool like Renovate, while Mend SCA protects cloud-native applications throughout the software development lifecycle. 

Best practice for vulnerability assessment on enterprise networks

The scale and pace of enterprise networks make automation and comprehensive solutions a must. We know you’re busy so here are just two very brief pieces of advice to consider.

Get fully covered

Combine SCA and SAST tools to ensure that your entire codebase is comprehensively assessed and protected. Use one unified solution to simplify the process for yourself and for your developers.

Make security easy to adopt

Automate remediation by using tools that integrate seamlessly into your developers’ workflow. Don’t make them have to remember to launch a tool; make sure it’s already in their preferred repository, registry, IDE, package manager, or build tool.

Vulnerability assessment: Make sure all of your bases are covered

Running a vulnerability assessment is the first step towards making your organization more secure but remember that there is still a long road ahead. Now is the time to follow up on the results of your vulnerability assessment, combing through the findings and remediating vulnerabilities along the way.

Security expert celeb Bruce Schneider is famous for saying once that, “Security is a process, not a product,” underlying the fact that it is not enough to have products that can perform scans of your apps, networks, and systems. What is needed is for everyone in an organization to ensure that they are updating to the latest versions of the software that they are using and following other security best practices to stay a step ahead of the attackers. 

Just remember that good security is practiced on an ongoing basis, not just at quarterly security reviews.

Another thing cybercriminals get is automation. Attacks are up and their rise is expected to continue, in no small part due to the fact that attackers are using automation to scale their criminal enterprises. With automated tools they can locate more victims faster, launch more attacks at once, and reach further along the supply chain than ever before. 

Well that’s just great. What’s to be done about it? The obvious answer is that software vendors must use defensive automation of their own.

The automation revolution in cyberattacks

Automation plays a significant role in the modern business of cyberattacks. Malicious actors use automation to their advantage to lower their costs, streamline their organizations, lend speed and scale to their attacks, and increase their chances of success. 

Here are just a few ways adversaries are using automation:

• Malware and botnets – The creation and management of botnets, networks of compromised computers which can be remotely controlled to perform various malicious activities including the distribution of malware, is largely done through automation.

• Phishing campaigns – Automated phishing kits are readily available for purchase on the dark web. These kits allow adversaries to easily create convincing phishing websites complete with fake login forms which can then be distributed, automatically of course, to a large number of potential victims.

• Credential stuffing attacks – Attackers use automated tools to test large lists of stolen or leaked username-password combinations against various websites and online services to gain unauthorized access. Let this be yet another reminder to not use the same passwords across multiple websites, systems, and services.

• Exploiting vulnerabilities – If you’re not scanning your code and infrastructure for security weaknesses, well you’ll never guess who is. Attackers employ vulnerability scanning tools to automatically identify security weaknesses in target systems, particularly outdated software and misconfigurations.

The race for automation in application security

Even with a generous budget for a large, well trained security team, manual testing cannot reach the scale, completeness, speed, or consistency of coverage that modern automated security tools can. Although manual testing certainly has its merits, it has many limitations that could have severe consequences for your organization.

And let’s face it, most security teams are overworked and understaffed. Here’s a formula that should help: automation plus a shift-left approach to application security equals shift smart. With the right tools, you can put some of the work of securing your code onto your developers and earlier into your software development lifecycle (SDLC) without slowing down releases.

Here are some automated application security testing tools you should be considering.

• Dependency updating tools – Chances are your software relies on a lot of open source components that are constantly releasing updates, many having to do with security. A good dependency health tool like Renovate enables automatic dependency updating by creating pull requests for your team to review and accept or reject. Free as both a GitHub app or self-hosted, Renovate also includes a Merge Confidence score to make decision making even faster and easier.

• Software composition analysis (SCA) – About those open source components… just because you have the latest version, doesn’t mean there aren’t still security concerns. SCA tools scan your open source code, including containers and other artifacts, and give you feedback on vulnerabilities. Advanced SCA tools (like Mend SCA) also give developers automatic alerts about vulnerable open source packages before a pull request is made and the component enters the system.

• Static application security testing (SAST) – For your bespoke code, SAST tools are used in both the coding and testing stages of the SDLC to analyze your code for coding errors and policy or regulation noncompliance that may indicate security concerns. We like Mend SAST, but we would – not just because we made it, but because it features automated remediation which writes the code to fix the security flaw for you.

Security everywhere all the time

Of course it’s not only automation that keeps attackers at bay. You also need to develop a good security culture in your organization that includes training and awareness programs, encourage responsible coding practices, and shift security left (and everywhere) so that it’s part of the fiber of your day to day activities.

But embracing automation in the SDLC with automated code review and continuous security testing must be on your menu if you want to have a robust and mature security program at your organization.

The bad guys are using automation to wreak havoc across the web. It’s time for the good guys to catch up and use automation to stop them.

But even if no one was asking you for an SBOM, knowing exactly which components are in your software is a major benefit to the security of your organization. When the next zero-day vulnerability hits, you won’t be scratching your head wondering where an affected package sits in your codebase, what applications it affects, or whether you even have that package in the first place. Sure, there’s more to staying secure and understanding your code than just generating an SBOM, and an SBOM is not the same as an inventory, but it’s a step in the direction of having clear visibility into your product.

Your customers deserve that clarity, too. Handing over an SBOM, especially in these still-early days of adoption, sends a strong signal that your organization is transparent, responsible, and secure, and it reassures customers and regulators that you are actively managing risks. Here is some advice on how to deliver that message.

Be secure

This one is basic but it has to be said. Simply handing over any SBOM isn’t going to communicate that your company has a serious and mature security program if you have major outstanding security debt. In fact, it will give your customers visibility right into your vulnerabilities, and if things are really bad they may, and rightly so, decide not to buy from you after all. So you need to actually be secure to show that you’re secure. There’s no way around it. Transparency is the whole point.

If you’re a little behind the curve here, the fastest way forward is to implement a software composition analysis (SCA) tool that will make a detailed map of all of your open-source components, give you a scored and prioritized list of your vulnerabilities so you can remediate quickly in a worst-first fashion, and automatically generate an SBOM for you. Again, there’s more to security than any one tool or process, but when it comes to managing vulnerabilities and SBOM generation, SCAs give you a lot of bang for your buck.

Be early

Take the carrot before you get hit with the stick. Get your company’s SBOM program going now, even if it’s not yet required, to show your organization is dedicated to security and compliance and get the kudos you deserve for strong leadership. You’ll spend a lot more money getting that infrastructure in place at the last minute, and you may lose money if customers go to a competitor who is already prepared to demonstrate their transparency.

Do it now, even if you’re not required to, because eventually you will be. And if SBOMs are already required for your industry, maybe you can’t be early but you can at least be on time. And you can go above and beyond by following our next piece of advice.

Don’t send an SBOM alone

By itself, an SBOM is unlikely to give a complete picture of your strengths or the true state of your vulnerabilities. When your customer scans your SBOM for vulnerabilities and licensing issues, they will probably get results that look bad on the surface but aren’t of any actual concern. They don’t know your software like you do, so it’s important that you include other materials that fill in the knowledge gaps. 

One such supplement is a list of your open source licenses, particularly dual licenses that you have purchased the commercial license for. Your customers won’t know that you have commercial rights to use open source licensed components unless you tell them.

Vulnerable doesn’t necessarily mean exploitable. Another document to include is what the NTIA calls a “companion artifact” to the SBOM, the Vulnerability Exploitability eXchange (VEX) file. Created exactly for this purpose, VEX allows you to provide context for the vulnerabilities in your software and communicate that you are aware of them and have investigated whether or not they are actually exploitable.

To sum it all up…

In this age of increasing digital complexity and heightened security concerns, the adoption of SBOMs is not just a trend but a necessity. True, governments and corporations have begun to demand SBOMs, but the advantages they offer extend beyond compliance requirements; they fundamentally enhance the security, transparency, and trustworthiness of your organization.

Moreover, embracing SBOMs sends a powerful message to your customers and signifies that your organization is committed to transparency, responsibility, and security. Being early in adopting SBOMs earns you recognition for strong leadership. Delaying may cost your organization more in the long run, both financially and reputationally.

But again, merely generating an SBOM is not enough; you have to back it up with genuine security. Transparency is meaningful only when it reveals a robust and mature security program. Address your security debt and take proactive measures to secure your software and the SBOM you send will sing your praises.

What’s taking security so long?

DevOps has been a recognized methodology for more than a decade, but organizations have been slower to embrace the security aspect. This may be a matter of incentivization, prioritization, and measurement. If your KPIs and the way you measure success isn’t based on security, then it won’t get prioritized.

There’s a large swath of tooling and responsibilities that DevSecOps encompasses and it isn’t always clear where these responsibilities lie. That’s because different companies place these responsibilities on different teams, all of whom are expected to roll into the DevSecOps principles and deliverables.

Certain companies, especially in regulated environments, have no choice but to ensure that security is baked into their processes. But if security isn’t already part of your developer workflows, it may take time to be adopted. What’s needed is clarity about responsibilities and more collaboration, especially if your company traditionally separates security from DevOps.

1. Bridge the divide between DevOps and security teams

Collaboration is important because it builds a successful DevSecOps culture across teams. Figure out how to put teams together to solve common problems. An example is introducing changes with pull requests, requiring reviewers from developers and security teams. If you’ve got the bandwidth, assign a security expert to the DevOps team and vice versa, so they understand each other’s challenges and how they go about solving them. Ensure that your DevOps team has KPIs linked to security. It amplifies the importance of security.

2. Control and automation

Collaboration presents its own issue among security teams: the issue of control. Much of the security integration into DevSecOps requires security teams to relinquish control and let developers and DevOps teams do the integration. That’s not easy for them, but a more collaborative approach requires sharing control, and figuring out the separation of duties, and how to ensure things are properly implemented.

Control is naturally averse to automation. DevOps engineers are by default people who embrace automation. It’s how DevOps has been able to scale and really accelerate. However, security teams have been slow getting into that game and still tend to do a lot of things manually, and reactively. It can be a big lift getting security teams to think of automation as a way to scale and get ahead of security problems, but it’s essential for scaling security reliably and delivering a robust and future-proof security strategy.

3. Balance speed and agility with risk management with automation

Businesses understand the value of agility, of being quick to fix bugs and introduce new features. We have to think about how security can be agile. This is where automation is key.

Automation is what our most mature customers focus on in DevSecOps because it improves the efficiency of your security tools. It means you can trust your DevSecOps. This is important when we consider that typically, security engineers are heavily outnumbered by DevOps engineers, so it makes sense to automate security testing and policies so that you can continue to develop software at pace.

When there’s usually just one security engineer for every fifteen DevOps engineers, automation removes the burden of manual scanning, checking, and remediation, and frees them to focus more on emerging threats and more complex problems. Automation helps security teams ensure that their business can keep moving at the speed it wants to.

4. Observability

Observability is critical to DevSecOps because you can’t secure what you can’t see. Successfully achieving it involves identifying issues and their potential problems earlier. Shift left closer to the source and before components are deployed or go into runtime. Then, you can find and address any issues before they have any impact. This optimizes the efficiency of your DevSecOps.

Nevertheless, after you deploy you may still find new vulnerabilities and problems, which feed back into the pipeline, and you need to establish who in the development circle needs to solve a particular problem. A lot of companies struggle with figuring this out. The answer is what we’ve called shifting smart, which is simply applying the practice of iterative scanning, testing, and remediation throughout the software development lifecycle (SDLC). This elevates the importance of observability.

In Kubernetes for example, observability plays a huge role. If you are dependent on your policy agents that you might have running in your cluster or scanning agents, you want to make sure that those services are available and successfully serving requests. Observability becomes part of the prerequisites of components that should be deployed to your system so that you have the necessary visibility to secure what you can see.

5. Avoiding alert fatigue

If you see more issues, you risk suffering from alert fatigue. You can avoid this by generating fewer alerts and reducing false positives. Software composition analysis (SCA) tells you whether you’re using a dependency that has a known vulnerability and if you might need to upgrade it. At Mend.io, we make the solution more mature with reachability analysis. This ascertains if a dependency is reachable or exploitable. If it isn’t, then don’t waste valuable time and resources addressing it. It reduces the number of alerts.

Automation also reduces the impact of alerts. Ultimately the reason people get alert fatigue is because alerts trigger them to take some type of action. When remediation is automated, fixing alerts is no longer a burden.  A better understanding of context helps you establish what’s critical. You may find a vulnerability with a high CVSS score, but is it in development, production, or in a runtime environment? Is it connected to anything else? Is it public facing? Is the component actually executed? These considerations affect how impactful a vulnerability could be and whether it’s worthwhile addressing. Contextual knowledge helps you identify when a particular risk should be prioritized, so you only focus on what’s necessary.

6. Legislation and regulation

There’s been a flurry of legislation lately around the world: the Cyber Resilience Act in the EU and the national cybersecurity strategy in the U.S. among others.

Regulation isn’t new in highly regulated environments, especially for government-related projects. But regulations will increase the importance of security strategy and accountability in all organizations. Software bills of materials (SBOMs) will be required to ensure that zero trust and software supply chain security are at the forefront of any projects. This new vigilance will drive more widespread adoption and maturation of workflows, especially those that demonstrate secure delivery of applications with increased velocity via automation.

Furthermore, regulatory compliance is a great way for security leaders to get their teams to adopt best practice. Ultimately, it’s a positive way for them to affect change that will help everyone get ahead of security problems.

7. Impact of AI and generative AI on DevSecOps

Perhaps the biggest risk of AI at the moment, but it’s hopefully something short-term, is what’s known as hallucinations in AI. That’s when AI is sometimes very confidently wrong and you can’t always trust it. With large language models (LLMs), in particular with generative AI, think of AI as an advisor and not a solution. View it as a way to make suggestions and generate ideas not necessarily seen before. You can use LLMs like GPT4 to give security teams an option on alerts to generate an idea of how they might solve them. But take note. Presently, proceeding with an AI-generated solution without due diligence could be risky. Some people will implement AI incorrectly and cause spectacular failures. Nevertheless, AI offers many benefits, especially when it comes to speeding up processes like scripting infrastructure as code, for example. My advice is: embrace this technology but be circumspect when using it.

Initially, the choice might seem bewildering, but it helps to know that a great SAST tool possesses ten essential features that optimize its effectiveness in finding and mitigating security vulnerabilities in your software and applications. Identifying these characteristics will help you select a SAST tool that best aligns with your organization’s specific needs and they’ll enable you to best strengthen your security posture against attackers. So, what are the top ten qualities you should look out for when you’re choosing a new SAST tool? Let’s find out.

1. Repository integration for comprehensive coverage

Your SAST tool should be integrated with your repository to help you resolve security issues immediately and avoid long backlogs by hardening your application security posture throughout the development lifecycle. This enables your SAST tool to do the following:

• Gain direct access to the codebase, allowing it to analyze the code comprehensively and identify potential security vulnerabilities.
• Facilitate automated and continuous code scanning, which is essential in modern software development practices, such as DevOps and agile methodologies.
• Keep pace with code changes and updates, to detect any security weaknesses introduced during the development process.
• Identify vulnerabilities early in the development lifecycle, reducing the risk of security breaches in production environments.
• Understand contextual information, such as the structure, dependencies, and relationships within the codebase. This understanding enhances the accuracy of security analysis and reduces false positives.
• Promotes collaboration and communication between developers and security teams by providing developers with timely feedback on security issues directly within their development environment, thereby creating a proactive security mindset, enabling developers to address vulnerabilities early and incorporating secure coding practices.

2. One security solution, for all code

If you want to be sure that you have comprehensive security cover, then you need the capability to scan and fix both open source and custom code. Most individual tools do either, but not both, which means you have the challenge of choosing, integrating and operating separate tools into your workflow. That can get messy and it presents the possibility that certain vulnerabilities could slip through the cracks. Ideally you need a solution that solves this issue.

Look for a security platform that can detect and remediate issues in both your custom and open source code. A provider that offers both obviates the need to integrate separate, different tools, and overcomes the risk of inconsistencies that might arise from such an integration. At Mend, our SAST tool for custom code is complemented by our SCA tool for open source, so you can be confident that all of your code is secured by one security platform.

3. Integration with the development workflow

Your SAST tool should integrate seamlessly into your development workflow. It should offer integration options with popular development environments, build systems, version control systems, and continuous integration/continuous deployment (CI/CD) pipelines. CI/CD integration enables you to scan code at various stages, thereby encouraging both shift left and shift smart practices. And integration ensures that security scans are automated and conducted regularly as part of the development process.

In the event of security issues, a SAST tool integrated into the CI/CD pipeline can prevent build failures. Such integration empowers the tool to promptly alert developers when they commit code containing security vulnerabilities, providing detailed information on the vulnerability and instructions for remediation. This integration also helps mitigate the risk of insiders introducing backdoors into the source code.

4. Automated remediation

Traditional SAST tools only focused on the detection of vulnerabilities in custom code, not remediation. Although this was effective in identifying issues, it left developers and security teams with the challenge of what to do to fix the issues they found. At best, these SAST tools could only provide training materials and examples to support developers in researching fixes for each security issue they encountered. Often this meant implementing manual, time-consuming remediation methods, which couldn’t keep up with the pace of development. This inefficient process forced developers to choose between security and meeting deadlines.

When faced with escalating volumes of code, and increasing pressure on delivering software quickly, you need a SAST solution that can expedite the remediation of vulnerabilities. This is achieved with an automated process. Seek a next-generation SAST tool that provides automated remediation, presented directly in your developers’ repository, for easy integration into their workflow. As a result, the application security burden on your developers is reduced, while the security itself is improved and accelerated.  Then development teams don’t have to sacrifice security for speed and they can be more confident about delivering quality, secure code, faster, and with a better ROI.

5. End-to-end security: enabling shift left, with the flexibility to shift smart

Discovering coding flaws at an early stage significantly streamlines the process of fixing them. So, it is highly recommended to shift security testing from the later phases to the earlier stages of the software development lifecycle — the SDLC. A good SAST tool does this, by seamlessly integrating with your repo and existing developer workflows. Shifting left allows developers to identify and fix vulnerabilities early in the development process.

We advocate going further than this by deploying end-to-end security. Ideally, your security scanning program should be able to detect and remediate vulnerabilities at every step of the SDLC. This means that your tool does even more than shift security testing left. It also shifts smart, by finding and fixing issues wherever and whenever they occur in the development lifecycle, and it achieves this by iterating scanning and remediation repeatedly and continuously, thereby maximizing the strength of your application security.

Check that your chosen tool can shift security smart, additionally with the ability to enforce security policies across your entire organization throughout the SDLC, and monitor security violations.

6. Speed and accuracy

In fast-paced DevOps environments, scanning speed is paramount. When a SAST tool becomes a critical component of the pipeline, slow scans hinder developer productivity and may lead developers to commit code less frequently or attempt to bypass security tests. To address this, SAST tools can accelerate scanning by caching results, running multiple tests in parallel using multiple threads and delivering prompt results.

Accuracy is also vital. False positives pose a challenge for security-focused teams. Dealing with false positives consumes valuable time and can contribute to alert fatigue. Furthermore, they can divert the attention of security personnel from genuine security issues. A good SAST tool minimizes false positives, using sophisticated algorithms and heuristics to prioritize the issues that could impact your organization most severely, whilst maintaining high accuracy. This approach helps minimize false positives, accurately identifies real security vulnerabilities, and reduces the time and effort required to review and remediate the issues that could really affect you.

7. Language and platform support

Your SAST tool should support all of the programming languages and frameworks commonly used in your software and application development. It should be capable of analyzing the specific technologies, libraries, and frameworks your code relies on to identify vulnerabilities effectively. This ensures that it can effectively assess and detect vulnerabilities in applications written in multiple languages, such as Java, C#, Python, JavaScript, and more.

8. Reporting and analytics

Thorough reporting and analytics capabilities are crucial for understanding the security posture of an application. Your SAST tool should generate comprehensive, concise, and actionable reports that highlight vulnerabilities, and their severity, and recommend remediation steps. It should offer guidance on fixing vulnerabilities, including code snippets or links to additional resources that developers can use to address the identified security issues effectively. It may also offer trend analysis and metrics to track progress in addressing security issues over time.

9. Flexibility, customization, and configuration

Your SAST tool should have customization and configuration options. Different projects may have unique requirements and coding standards, so the tool should provide flexibility to adjust scanning rules, severity thresholds, and other settings to match configuration requirements. A flexible SAST tool allows customization to align with specific security policies and coding guidelines so that you can add custom rules and checks to address project-specific security concerns and meet your organization’s specific needs.

This can prove to be particularly important in certain industries where compliance with security regulations and standards is mandatory. A robust SAST tool should support compliance requirements and assist in auditing processes. It should include checks for common regulatory frameworks such as OWASP Top 10, PCI DSS, HIPAA, and more, and should have the capability to accommodate others as your codebase grows and diversifies.

10. Scalability, extensibility, and ease of deployment

The volume of components and dependencies within codebases continues to rise rapidly. As it does, the network of relationships between these components and dependencies becomes more complex, the attack surface grows, and the potential for vulnerabilities to proliferate escalates. Therefore, the scalability of a SAST tool is vital for large and increasingly sophisticated codebases, or projects with frequent code changes. Whatever SAST solution you choose must be capable of scaling up as your codebase expands with more components, updates, and the like. It must be able to handle complex applications efficiently and deliver results within a reasonable time frame. Scalability ensures that the tool can adapt to growing codebases and provide consistent performance.

These characteristics will keep your SAST strong

The cybersecurity landscape evolves rapidly, with new vulnerabilities and attack techniques emerging regularly. A SAST tool that demonstrates these ten qualities will serve you well now and, in the future, with the capability to keep up to date with the latest security standards and best practices. As such, it will be a valuable tool for assisting developers in their day-to-day activities, minimizing security risks, making the software and applications that you use and distribute safer and better for all users, and helping to ensure that your organization, your reputation, and your customers are protected from proliferating cybersecurity threats.