Many teams think of DAST as almost an afterthought, just the dessert you may or may not order just before the software is released. But modern DAST solutions offer powerful insights necessary for a well-balanced security posture.

Why organizations sometimes restrict DAST scans

Before we get into suggestions on why and how to run DAST scans more frequently, let’s talk about why many organizations have limited their DAST scans. Typically, these reasons include:

• Time constraints. DAST scans can be time-consuming, especially in large applications. Many teams struggle to balance comprehensive security testing with the need to meet tight release deadlines.
• Misconceptions. Some believe that DAST is only part of QA or external pentesting processes.
• Manual intervention. Some DAST solutions require manual validation or configuration adjustments, adding extra work to already busy teams.

Despite these challenges, there are ways to integrate DAST more seamlessly into the development pipeline that allows teams to run more frequently and catch issues earlier.

Have your cake: the benefits of running frequent DAST scans

Running DAST scans once a quarter or only before a major release can create blind spots where vulnerabilities are introduced but remain undetected for extended periods. Here’s why running DAST scans more often makes sense:

• Early detection. Frequent scans allow teams to catch vulnerabilities as soon as they are introduced, rather than at the end of a release cycle when they may be more difficult and costly to fix.
• Updated feedback. Security testing should be proactive, not reactive. Frequent DAST scanning provides steadier, more regular feedback to developers, allowing them to address vulnerabilities in smaller and more manageable increments.
• Risk minimization. Every day that a vulnerability goes undetected, an application is at risk. More frequent scans reduce this window of opportunity for attackers, strengthening your application’s overall security posture.

Mend.io + Invicti

See how Mend.io and Invicti extend your AppSec coverage from code to runtime.

Download the solution brief

Adding DAST to your daily diet

To make DAST scans a more regular part of your development cycle, it’s essential to address the time, resource, and manual intervention barriers. We recommend the following tactics:

1. Automate DAST in your CI/CD pipeline

One of the most effective ways to run DAST scans more frequently is to integrate them into your CI/CD pipeline. By automating the process, you eliminate the need for manual scans, allowing DAST to run automatically whenever code is committed or deployed. Use incremental scanning to focus on only the recently changed parts of code, saving time and resources.

2. Use cloud-based DAST solutions

Traditional on-premises DAST tools can be resource-intensive, but modern cloud-based DAST tools offer scalability and flexibility. By leveraging these improved solutions, teams can offload the heavy lifting away from local resources.

3. Run scans in parallel with other tests

DAST can be integrated with other testing processes to run in parallel and reduce bottlenecks. For instance, while functional tests run, a DAST scan can simultaneously check for vulnerabilities. When DAST is integrated with other types of testing, teams can get a holistic view of both the functionality and security of their application in one go.

4. Collaborate with developers

Security is a shared responsibility. By working closely with developers, security teams can ensure that security is considered from the earliest stages of development. Frequent DAST scans help security teams provide more on-time feedback, empowering developers to write code that’s less likely to introduce new security issues in the first place.

Application security food groups: better together

Static Application Security Testing (SAST) offers a chance to find insecure coding early, before it goes anywhere near production, but some things still fall through the cracks. DAST helps teams discover vulnerabilities that make it into the build.

Utilizing both SAST and DAST frequently helps security teams stay on top of vulnerabilities and provide developers with crucial and on-time feedback about the security of their code.

With that in mind, Mend.io has partnered with Invicti to provide comprehensive solutions and pair Invicti’s DAST and API Security domains with Mend’s SAST, SCA, and Container Security solutions to give customers full code coverage and continuous security. One login grants access to everything you need from vulnerability scanning, analysis, and tracking. It’s like having a master key to the entire AppSec kingdom.

I’m back from another Black Hat! It was great seeing everyone. I put out a message on LinkedIn for people to come find me and, boy, did they. The hallway conversations were so engaging, I was sometimes late getting to the official talks, but I’m getting ahead of myself.

AI was everywhere, as we’d expect, but I also sat down to listen to experts on other topics like critical infrastructure, cyber insurance, and the root causes of cybersecurity failure.

Here’s a brief on what I loved and learned:

On AI

AI Safety and You: Perspectives on Evolving Risks and Impacts

Nathan Hamiel (Kudelski Security), Dr. Amanda Minnich (Microsoft), Nikki Pope (NVIDIA), Mikel Rodriguez (Google)

This excellent panel included some really heavy hitters, and my takeaway was that there’s a lot more bad than good with AI. According to the panelists, we’re very close to the point where we won’t be able to identify that a deepfake is a deepfake, and that’s scary stuff.

So what’s being done about it? Guardrails are the typical answers but these panelists–red teamers all– think people will find ways around whatever guardrails are put up. Instead, they suggest that AI models must learn the difference between right and wrong at the model level. If we can achieve that, then the models become like toddlers that can touch a hot stove and learn never to do that again. If that doesn’t happen…Lord help us.

Threat Hunting with LLM: From Discovering APT SAAIWC to Tracking APTs with AI

Hongfei Wang, Dong Wu, Yuan GU (All with DBAPPSecurity)

In slightly rosier news for the future of AI, these researchers talked about how they’re using LLMs to detect and find malicious code. They were able to train their model to recognize what malicious code looks like and were able to then use it for future detections, which included binary code, encoded code, and normal text.

On industrial control systems

ICS Risk Management: Strategies for Assessing and Mitigating Operational, Safety, Financial, and Cybersecurity Risks

Cassie Crossley (Schneider Electric), Noam Moche (Claroty), Thomas Brandstetter (Limes Security), Daniel Cuthbert (OWASP, UK Government Cybersecurity Advisory Board)

This was a really eye-opening talk about all of the valves, switches, and other internet-connected things used in critical infrastructure. Many of these devices can’t be shut down so when you’re working with them, you have to think far ahead and outside the box. There are a staggering amount of devices on the internet today that were never designed to be on the internet. The major takeaway here was that manufacturers need to plan ahead and be forward-thinking regarding how their devices might be used. You never know what an end user might try to do. 

On root causes of cyber-insecurity

Keynote: Democracy’s Biggest Year: The Fight for Secure Elections Around the World

Jen Easterly (CISA), Hans de Vries (ENISA), Felicity Oswald OBE (NCSC), Christina A. Cassidy (Associated Press)

The overarching message of this keynote speech seemed to be that no matter how much money we throw at cybersecurity, we’re failing. When you take a step back and look at what the root cause is, it’s clearly software that wasn’t developed to be secure in the first place. It was announced that a new government initiative will be kicking off soon focusing on developers and even potentially holding developers liable for security to some degree.

On cyber insurance

Strengthen Cybersecurity by Leveraging Cyber Insurance

Bridget Quinn Choi (Woodruff Sawyer)

This was an interesting talk. Choi is a lawyer who handles cyber insurance policies, and she spoke about the origins of cyber insurance and how it has evolved. She cleared up some misconceptions and stressed that what cyber insurance should do is to help companies avoid being financially and reputationally devastated. Today, cyber insurance companies have teamed up with endpoint detection and response (EDR) companies, and policyholders get a discount for using particular EDR products. It’s a good thing that more people have EDR, but I’m hoping these products are actually good and effective.

Hallway conversations (on everything else)

A big theme was that every day data is being stolen, and there seems to be nothing we can do about it (which certainly mirrors the keynote panel). Companies are feeling like they don’t know what to do or that they have clear direction on how to be secure.

While many of the CISOs that I talked to certainly knew their stuff, many are new and feel overwhelmed by the sheer amount of things to know and protect. Not surprisingly, the trend seems to be that the title CISO doesn’t mean just one thing. Back in the day, CISOs used to be over literally everything security. Now it seems there’s a split with CISOs who cover the networking and AppSec side, and other kinds of CISOs who cover just policies, legal, and governance, risk, and compliance.. There really is so much for these people to cover so I wouldn’t be surprised if new titles emerge to better describe these two distinct positions.

On 2025

AI and LLM modeling will make unparalleled progress. When you stop and think about AppSec specifically, the progress over the last 10 years has been dramatic. Gone are the days of being a niche area—we’re just about mainstream. This next year will have a lot of growing pains but I think we’ll move the needle more than we have in multiple previous years combined.

This is a public service announcement:

The not-so-simple act of securing applications produces a lot of documentation, including playbooks and policies, that isn’t typically needed on a daily basis. But when a zero-day event occurs, such as the recent Crowdstrike incident, application security teams better be able to find everything they need—and fast. Sadly, in both big and small companies, missing and outdated documentation is rampant.

Hopefully, your documentation isn’t solely residing in someone’s head. (This may not happen often, but we’ve all heard stories.) If it is, you’ve got a much bigger problem to address, and that’s beyond the scope of this blog. 

A much more common issue is that the location of the documentation is in someone’s head, and that someone may no longer work in that department or even that company. That’s really not much better. Both employee promotions and departures can leave teams without access to necessary documentation, and hours can be wasted searching for them.

Missing and outdated documentation can considerably slow down an application security team’s incident response time, which of course increases risk. It can also waste time in less direct ways. If your developers can’t find application security documentation like best practices and architecture suggestions, they may simply ignore those requirements. And if they then go on to build something insecure that needs a lot of remediation work, that can be many, many hours wasted.

Location, location, location

The next time you do a tabletop exercise, take out a stopwatch and see how long it takes for someone to find the right playbook. Was it more than five minutes? Way more? It should be less than one. 

It’s important that application security documentation can be found when it’s needed, and that means it needs to be somewhere where people know to look for it. That place is not twenty folders deep on a drive named “beware of the leopard”. It should be, however, a secure storage solution.

Yeah? Who wants to know?

Sometimes the documentation exists and is in a pretty reasonable location, but there’s no process to let the right people know about it. SOCs, NOCs, developers, leadership—lots of teams need ready access to security documentation. The onboarding process for new employees and contractors should include education on the purpose and importance of documentation, clear instructions on how to use it, and where to find it. And of course, only authorized personnel should have access to your documents to prevent sensitive data from getting into the wrong hands.

Keep it current

Sometimes teams can find the documents, but the information in them is outdated and of limited use. The playbook says “Call Wendy.” Who is Wendy? Oh, she left that role five years ago.

Living documents are kept up to date through staff, policy, and industry changes. There are plenty of options—Confluence and Google Docs are two—for creating and hosting these documents; just make sure you use something with version control.

Different companies will need different policies on how often they update various documentation. It’s not a bad idea to give them all a once-over every quarter and after triggering events, like a senior employee moving to a new role or company. You also need to specifically assign that responsibility to somebody.  

That said, there’s still room for securely stored hard copies. If your whole network goes down, a printed copy of the appropriate playbook will be a lifesaver.

If you know, you know

Good documentation makes the security world go round. Where you store it, how you store it, and who you tell about it are all vital to keeping your company secure and able to quickly react quickly to developing threats.

Turnover

I am lucky, I get to talk about application security with hundreds of companies each year. And over the past year and a half, I’ve noticed that many have had a complete turnover in security staff.

What does this mean? Tools that were purchased by previous teams are either going unused or on auto-pilot. Alerts and notifications are going to email addresses that are no longer being monitored. Some companies do not even realize that they have some of the tools they have. 

My advice is to take a moment and do an inventory on what you have. Talk with your purchasing department and get a list of tools that were purchased by the previous team. Take a moment to call each company and talk with them. Ask for a demo on the tools you have and ask how to use it. Maybe the tool is not needed, or maybe it’s the lifesaver you have been shopping around for and you already have it.

(Re)building strong relationships

A complete security staff turnover not only affects technology usage. All those relationships that the security team had with development disappeared as personnel walked out the door, and the new team must rebuild them. Here’s what I suggest: 

Spend time with development. Leave your desk and take a trip over to where the development team sits. If remote, then reach out to the team leads or architects. Discuss how things are going and rekindle the relationship that was lost when the previous team turned over.

At a previous employer, I would always take time to walk around the development floor and see how things were going. This will give you insight to new products and tools that teams are building. The information gained is invaluable because it keeps you in the loop and you can plan accordingly.

And about those tools…

So maybe you don’t already have the tool you need, and the search continues. Here’s something to consider as you do your due diligence and establish your needs: 

Would you hire a plumber to do a whole house inspection? Would you hire a general contractor to fix foundation issues in your home? Would you hire a teller to audit your 401(k) account? Finally, would you hire a foot doctor to do surgery on your back?

What do these examples have in common?  The person being hired knows some of what needs to be done, but not everything. Why would you do the same thing for your application security program?

Make sure that you are properly staffing your programs with people who understand all aspects of security. Using your cloud security guy with no development background to handle SAST could lead to disastrous results and additional risk.

Knowledge is key in each aspect of your security program. Several vendors provide great tools, it’s a matter of understanding what value they can bring you and how they can be integrated.  I understand that it can be more expensive to have a la carte security, but how much does a compromise cost?

Use your tools correctly and tune them for success. Clicking the “WAF” option in AWS does not mean you have a fully working and deployed WAF solution. These rules need to be fine-tuned by someone knowledgeable to be successful.

If possible, hire an on-premises penetration tester. Have them validate critical findings that could ruin your day. Share the actionable findings with development -– ideally via a recorded video so that they will know exactly how and why the finding is important. It will go much further than just giving them a report of 5,000+ potential security issues from a security tool.

To next year

Every year we see new technologies and new vulnerabilities, but the basics of cybersecurity tend to stay the same: building relationships with staff and taking care to purchase and implement the best security tools for the job. So here’s one last piece of advice that covers both: talk to your developers about tools before you buy them. Developers are busy, of course, but let them own some part of the process and you’ll get much better buy-in later. Do not be a roadblock, but come alongside development and work together to incorporate good security practices. Work together as a team and you will accomplish so much more.

As always, stay secure my friends.

Driving forces

71% of IT and security leaders say their portfolios of applications have become more vulnerable to attack. We saw a 33% rise in the number of open source software vulnerabilities added to our vulnerability database in the first nine months of 2022 compared to the same period in 2021. Open source vulnerabilities more than doubled from 2018 to 2020, and software supply chain attacks are expected to triple by 2025. Nevertheless, as open source code is used in 70% to 90% of all applications today, applications face significant risks.

We have also seen a steady increase in the number of malicious packages. Data from Mend Supply Chain Defender shows a steady quarterly increase in malicious packages published in 2022, with a significant jump in Q3. At least ten are published each day to npm and RubyGems, showing that attackers are deploying new techniques to disrupt organizations’ applications.

As more development teams move to open source and as attackers become more sophisticated, traditional application security programs often prove ineffective, because they don’t keep up with today’s trends. Application security often conflicts with ever-accelerating development lifecycles, and as a third of global companies are expected to move more than 75% of their workloads into the cloud, the hits just keep coming. What’s needed is a new, modern AppSec approach that’s more nimble and ready to react.

The new approach: five key principles

At the core of a modern AppSec methodology are five key principles that will harden your security:

1. Preparation and planning to maximize visibility. You can only protect or fix what you know you have. Ensure you know the contents of your open source, and how it’s stored and used. Use a software bill of materials (SBOM) to do this. Continuously review and update this process to stay ahead of new vulnerabilities and attacks. Always know who has access to your code, software, and data, and be sure you regularly update components and dependencies. Moving to the Cloud can be beneficial because there are lots of great tools that cloud service providers offer to help you.

2. Don’t just shift left. Shift smart. Shifting left — performing security scans early — improves security, but don’t stop there. Shift smart. This means integrating vulnerability prioritization and remediation tools into your team’s development environments, inside your code repositories, your build servers, and bug-tracking tools to address potential risks as soon as they arise. By shifting smart, you put security in developers’ hands during development, and you make it easy and quick for them to fix their code.

3. Automate. Automating processes addresses the need for speed and detection, triage, and response, while easing the stress caused by the ongoing shortage of cybersecurity professionals. It saves time and reduces risk by ensuring all current versions are in use and deploying solutions that automatically detect and remediate vulnerabilities. Companies can make it easier to integrate application security into the software development lifecycle using tools such as Mend, especially if you’re using GitHub or other repositories because pull requests will automatically either bring you a less vulnerable version or take you to the latest version. With our Merge Confidence feature, we can give you a score that shows whether you’ll have minimal issues or no issues at all with any particular libraries or updates.

4. Apply good governance. Having a robust process and a good cybersecurity incident response plan is vital, but many organizations neither have them in place nor apply them consistently. Also, it’s important to regularly review and test processes, to improve visibility and applications, assess data and rapidly update vulnerabilities and patches. Create playbooks and run drills to ensure you can address the newest vulnerabilities and threats.

5. Change the culture. Inculcate a security mentality throughout your teams, your SDLC, and your organization. Security is a collective effort. Goals must be aligned between security and DevOps teams. Best practices must be applied by all, but make sure they don’t become so onerous that they’re ignored or avoided altogether. Listen to your teams’ needs and concerns to find ways to integrate and automate the process so that they readily adopt security best practice. Appoint security champions on each team. They can spearhead best practice at every point in the SDLC, build trust in the process, and improve the often fraught relationship between security and development teams.

The ingredients for success

Applying these principles will harden your application security posture. This is critical now that organizations increasingly rely on apps to drive their businesses. As apps proliferate, the attack surface expands, and they become an increasingly attractive target for smart attackers. You need to ensure that your application security can keep pace with them. These principles form the foundation for modern AppSec strategies, making them nimble enough to adjust to changing conditions and handle a constantly evolving threat landscape.

Clearly, if you don’t already have a modern application security program, you need to build one. But how do you make sure that your program will be effective? Let’s start with the following tips. 

1. Find out what you don’t know

It may sound obvious, but you need to identify what you don’t know to find crucial knowledge gaps and identify issues. This means asking a lot of questions, starting with the following: 

• Where is your application used?
• What languages does it use?
• How does it communicate?
• Does it communicate externally and/or internally?
• Where are the authentication details stored, a database, an active directory, Okta?
• If they’re in a database, do you store your credentials securely? Are they hashed?
• Do you store credit card information and if so, all or some of each card’s details? Could this information be critical in the event of a breach?

2. Educate from the top down

To successfully integrate application security across the entirety of a development program. everyone plays a role, from the C-suite all the way down to the developers. Here are some ideas to get everybody on board:

• Communicate with the C-suite. Make sure that the CEO, and CIO, all the way from the top down, understand what you’re doing and the tools that you’re using. If there are any gaps, ensure they know, because it’s crucial that they buy into the need for modern security in today’s environment.  
• Hold an annual company-wide meeting to explain your security program to your developer community. Sharing this information company-wide helps to build a relationship with developers. The last thing you want is a situation where the security team and the development team don’t work together. When that happens, nobody wins.  
• Monthly reports to executives. It’s crucial to keep your executives in the loop about where you stand with your security program today, especially if you have teams that are struggling to put resources together to resolve security issues. With up-to-date knowledge, executives are better placed to make judgments, such as reconciling developers’ need to ship product with security’s need to scan and check.
• Monthly newsletters to developers. Publishing regular newsletters to teams of developers gives you an opportunity to highlight news and developments, recent threats and fixes, and current examples of how others have handled them. This is a great way to learn from others how to avoid or overcome the same issues before they impact you.

3. Bake application security into developer onboarding

Start your security training as soon as any new employees arrive. Have a member of the security team spend 45 minutes to an hour talking with everybody about your security program, what tools you’re using, and your approach to security. (At the very least have a recording that you can share.) Then, when your developers start working, they will have the same information and knowledge and you’ll have started them off on the right foot.

Ensure that your developers feel comfortable talking with the security team so that both groups understand the other’s priorities and can work together to overcome any differences. This will encourage developers to make security part of their regular working practices and will hopefully minimize any friction between teams. Also, make sure that your developers understand the tools that you’re using, where they’re scanning, and what the tools are searching for. That’s a process of education and is best performed when working together.

4. Show, don’t tell

Show your teams that they have an issue. It’s more impactful than just telling them, and it gives everyone a stronger sense of urgency to get things fixed.  One idea is to create a presentation where you go out and attack your internal software, record your attack so that you can revisit it, and show it. In the process, you start to build a library for yourself.

Another method is to  take your build, install it on another machine, and then try to decompile it. This will give you a good sense of how robust your application security really is. You should make sure that you obfuscate your applications so that nobody can decompile it.

5. Attack your software

Similarly, stress test your own software by attacking it. Penetration testing is critical to ensuring secure software. Go into your security tools and take the most critical items that you can find in your reports, like command injections.

You can have a third party check your application with penetration testing. But they don’t have access to all the details and the data, so they’re likely to come in and blindly start attacking you. If you assign the job to your security team, or if you have a developer that understands what they’re looking at, you can test more precisely with more targeted attacks, so you know where you should try to dig a little bit deeper.

If you’re releasing source code or applications on the web and you’re not taking these little extra measures, hackers will be waiting and looking for code like yours that has vulnerabilities. Be mindful that there are companies out there consistently scanning every single IP address, saving that information, and putting it on a search engine to look at.  If you’re not doing anything like this internally, the hackers already have this information, and they’re ahead of you. Again, knowing what you don’t know is important. So don’t limit your penetration testing. Make sure you’re in an environment that is not production. And make sure that the different internal teams know that this is what you’re about to do or what you’re actually doing.

If there are security alerts and monitoring in place, you’re going to trip those. That’s excellent, as you’re getting into the mindset of the attacker so you can learn what to avoid and what needs securing.  

6. Build bridges with security champions

Security champions are a great extension of any security program because they can keep their ears to the ground with different teams working on niches within your organization. A security champion on each team has a better understanding of their work and where security issues might arise on specific projects. They can attend the senior tech reviews. They can attend and understand the scrums. They can look at what’s going on, what features are being included, and any problems that are emerging. Security champions can make sure that the security team is coming up with ideas to promote security and ensure that all teams are focused on it. Maybe it’s security awareness month, or weeks when there’s a focus on something specific, like APIs or cross-site script injections. In fact, a good security champion will not only relay important information to the development community, but will also provide feedback to the security exports so that programs, processes, and education efforts can be continuously refined.

This program can work in many different ways. If you’re a smaller company, you might take a champion — a developer — and just make them security only, with a dotted line to the security team, although they’re still in the development arena where they can oversee multiple things. Alternatively, they might split their time 50/50. 

Perhaps there’s a large number of developers in your organization and maybe a small cohort of champions. They can share information with groups of developers. Perhaps you’re an international company with people in numerous countries. By appointing security champions, you have people on the ground who understand the local languages and can relay information and educate teams about good practices in a positive way. And from there, you have built the foundations of a robust application security strategy with a framework for continuous improvement that will set you up well to handle the challenge of a fast and constantly evolving application development environment.

More and more companies are using more and more open source. The stats I’ve seen say seventy to seventy-five percent of all applications use open source or have some type of open source associated with them. I think that number is actually higher. Of all the companies that I’ve worked for, just about every single application has some type of open source associated with it. And the more you use, the more this multiplies because each piece of open source has components and these components have dependencies.

The proliferation gathers pace as it progresses. For instance, you may take two or three open source libraries and apply them to your application. But underneath the covers, you may have multiple open source libraries associated with them. If you’re doing something like a simple file upload, you may only have one or two sub-dependencies, but if you’re doing something more complex, such as with languages like Angular, you could easily have thirty or forty, and the thing that you have to contend with is not only whether your direct dependencies are using indirect dependencies, but whether there could be indirect dependencies in other tools. So, it could grow to hundreds in certain circumstances.

Plus, when you’re looking for an open source library to plug into your application, it’s not necessarily clear what all the licensing models are that are associated with it. A library might follow the MIT model, and you think you’re safe, but a transitive dependency could be hidden beneath the surface that’s A GPL, which has a different set of challenges that need to be managed. It can therefore be quite a drill-down for a license management tool to cover everything.

Challenges and opportunities of open source licensing

There’s a push-pull dynamic between developers and their companies’ needs. Developers use open source code and the capabilities it brings to build new applications. Understandably they’re enthusiastic about this, and about the principle of open-sourcing their own applications.

However, companies realize that they need to protect some of their output. They don’t necessarily want total permissiveness within their environment because they don’t want to have to open source their systems completely. But licensing restrictions discourage sharing and adaptation of developers’ libraries, however amazing they are, so they seek to use less restrictive licenses like MIT, BSD, or Apache. That’s where the multi-license model comes in, to try and reconcile the differing terms and conditions of various licenses. Consequently, more companies have become aware of the need to follow multiple licenses and the multi-license model.

Developers’ priority has always been productivity rather than licensing and compliance. In my thirty years of running teams writing software, licensing wasn’t our concern beyond knowing we didn’t want to use anything super-restrictive. I’ve been through numerous mergers and acquisitions, and it was amazing to see the kind of freedom that developers had. When they found a library they needed, they simply took it and used it.

Even when performing due diligence, the focus was traditionally on security rather than licensing. Teams wanted to know if they were creating a risk by deploying applications and if there are any vulnerabilities that could expose the company to threats. Licensing was an issue for the legal department.

What happens when you don’t take care of your licensing? The Linksys router story

The following story is a great example of why companies must take care of licensing. Back in the 1990s, Linksys produced an effective, inexpensive, and hugely popular router, the WRT54G. By 2003, Andrew Miklas, a contributor to the Linux kernel email list, noticed that the router’s firmware used software based on Linux. Under the terms of use, Linksys — now owned by Cisco — had to release the firmware’s source code.

An unforeseen result of making the source code available was that people could modify the firmware themselves and change the router’s capacity and usage in ways that the company hadn’t anticipated. Cisco found itself selling cheap hardware with capabilities that far outstripped its price point. It released an “upgrade” with its own proprietary firmware, limited RAM and storage, which would make it difficult to replace the firmware with third-party versions, but unsurprisingly, users weren’t happy, and eventually, it re-released a Linux version of the router, with the original specifications.

Do some industries take licensing more seriously than others?

Corporations that handle obviously sensitive information, such as patients’ electronic health record systems or financial records, take licensing issues very seriously. Also, any government organizations and those that provide critical infrastructure, like the power grid. But I think there’s increasing awareness across the board.

That’s because if you open-source your software, you’re potentially giving everybody the keys to the kingdom, your source code. Hackers realize that they can inject malicious code, recompile it, make it look like the original, and work like the original, and nobody’s going to know. And with access to source code, they can manipulate your environment, the administration, the privileges, and the access you have set up, so they can infiltrate and cause havoc at the source. The risks manifest themselves primarily in vulnerabilities that enable hackers to disable, steal or manipulate data, money, assets, and more.

The toughest challenge for open source license management

With this in mind, it’s critical to know what you have in your open source libraries and ensure they aren’t exposed. Know what you have in production and understand what your risks are. Technically, what’s in development and not yet in production, doesn’t need such strict due diligence. However, once you put it out there for people to use, it’ll become obvious what libraries are being used, and whether you followed the terms of usage. Furthermore, and perhaps even tougher, is not only knowing what licenses are in your environment, but also anticipating what the impact of those licenses might be.

How to address this challenge?

You need a license management tool that gives you comprehensive visibility. For example, a tool like Mend will tell you that you have a GPLv3 component in your codebase. You can go into the tool and see the usage details in the form of the actual license text. A screen tells you what the copyright risk score is, and the details around it, so you have an idea of the impact of your redistribution of this component. It tells you if there are patent or royalty risks assigned to some of your open source libraries, which require payments and which are royalty-free, for instance, and we give you the copyleft detail. Risk is shown in an easy-to-understand traffic light system, so you can tell at a glance what might be problematic and what to avoid to prevent legal problems.

Which types of licenses present the most serious risks?

Risks differ based on the context in which software is used and how it’s intended to be used. So, it’s hard to say what are generally the worst licenses. Mend helps by showing the licenses you should avoid in red, directly on the dashboard.

If I were to advise avoiding one particular license, it would be GPL. That’s because it’s copyleft, you have to disclose your source every time, you have to provide your license and copyright notices, and in some of the licensing models out there, you have to disclose what libraries you’re using. Sometimes you even have to acknowledge your application in a file publicly, to show that you’re following the licensing model precisely.

That’s very transparent, but it also can leave you exposed.

What should you look for in an open source license management tool?

Your open source license management tool should be:

Comprehensive. Does it tell you exactly which licenses are being used when you’re creating an application? It’s important to have a system that tells what are both your direct and transitive dependencies because you need to know the entire scope of your licensing and vulnerabilities.

Clear. Your tool should clearly report all the details about your code base. Mend’s risk report shows you precisely what licenses are attached to a project. It tells you what your risk is at a glance, and it shows you exactly what license conditions you must comply with.

Fast and seamless. Developers must ensure that FOSS (free and open source software) goes through the QA process before plugging it into their application. If a tool gives you all the details about the libraries you’re using in a report, you can simply give it to the approving team, so they can make decisions more quickly about which licenses you can use.

Easy to use and understand. It sounds obvious but an open source licensing tool can only be effective if most or all of its potential users within an organization actually use it. So, it should be easy to use, and its UI and UX should be easy to understand. A good tool distills all the licensing information into compliance reports that are very simple so you can easily make sound judgments about risks like copyright, patents, and royalties. Mend’s tool does this. It generates visually impactful dashboards and screens so that this complex information can be understood at a glance.

Highlighting and implementing updates. A good tool not only hits the licensing issue but also provides great vulnerability data. This enables you to identify and upgrade to new versions of components and dependencies at the click of a button. Your tool should show you the versions you’re running and the available upgrades and recommend what to switch to. This means you continue to comply with licensing criteria while simultaneously reinforcing security by implementing the newest versions that are likely to be less vulnerable.

Setting up policies and alerts. Your tool can make license management easier by setting policies, and when they are breached, alerting users so that they can address the issues quickly. Ideally, your tool should even prevent building with non-compliant components to ensure you don’t introduce any risk to your applications. Mend’s tool can set policies at both the product and organizational levels and can automatically reject components that don’t comply with your policies.

Best practices for choosing an open source license management tool?

Perhaps the most important thing is to allow your developers to find the license management tool that fits them best. Then it’s a case of ensuring that it’s thorough so that developers get all the information they need to do in-depth due diligence.

If your developers want to introduce a new license, they must provide a risk report to the senior tech review, because they are the guys that need to know if something new has been introduced to your code base, so they can check it. They will be the ones to confirm whether the license of what has been introduced is compliant. Your tool must be able to facilitate this process.

The next question is whether a license is company-approved. That means passing it by your legal team to check whether a new library is on its approved list. You need to ensure that your tool enables you to submit libraries for review, so you can examine the licenses associated with each library.

You should be able to view and assess any dependencies — direct or indirect — so that you can see whether you risk introducing threats to your application by taking a particular library. And you need to see what the vulnerabilities are that are associated with each library.

What’s next for open source license management?

I think that open source license management is going to get more challenging. You’ll see more of the push/pull effect between permissiveness and protectiveness. Companies are more willing to use open source software, and a lot of newer licensing models are emerging that bring more freedom than a GPL. But companies still want to be able to protect themselves and their intellectual property. Therefore, there’s a persistent tension between everybody using open source licenses, and users wanting to make them more restrictive over time if they prefer.

A good example of this is Java. Java’s runtime engine used to be free, and they decided at one point that they wanted to monetize it by charging for use. But when they started charging for licenses, almost nobody used the new version. Everybody downloaded the old versions. Java realized that this could kill its product, so it suddenly changed its tactics. It still gave away its tool for free, with a few more strings attached, but still permissive enough for everybody to use further forthcoming versions.

This is the type of story you’re going to see repeatedly. Now, more companies release new open source features, libraries, and tools because they know it’s beneficial to themselves and their industries. Nevertheless, they want to ensure they have some control over them, so they can maintain their points of difference from their competitors. It’s a balancing act that will continue to exercise those of us concerned with open source license management.

1. Discuss the ubiquity of open source software 

Between 70 and 90 percent of all software and applications contain open source components, which represent a growing security risk. In Forrester’s State of Application Security, 2022 report, the research firm found that software applications are the favorite attack vector of malicious actors. According to the research, 53 percent of external attacks involve either exploiting a software vulnerability or come through a web application.

Even more alarming, open source vulnerabilities proliferate at a rapid rate and this growth is expected to continue. The Open Source Risk Report found 33 percent growth in the number of open source software vulnerabilities that Mend added to its vulnerability database in the first nine months of 2022, compared with the same time period in 2021.

Furthermore, 71 percent of IT and security leaders say their portfolios of applications have become more vulnerable to attack. These trends show that vulnerabilities pose a serious risk for every organization that uses open source to help build their applications and software.

Hacker tools already identify which open source components are being used, along with associated vulnerabilities. If they already know this information, you should as well. 

2. Show why SCA is the gold standard 

SCA is specifically designed to analyze and fix open source vulnerabilities, making it a first-choice solution given the ubiquity of open source components in today’s applications and software.

SCA tools scan the code base of your software and applications to identify all open source components, their license compliance data, and any security vulnerabilities. Modern SCA tools like Mend SCA, also fix open source vulnerabilities by prioritizing and automatically remediating those that pose more serious risks. Previously, there was a trade-off between developers’ productivity and security, but now, SCA tools overcome this issue by working within the current development workflow, making the process of applying security measures as frictionless as possible in the SDLC.

Consequently, modern SCA products can offer better detection, greater accuracy, and faster remediation of vulnerabilities than legacy SCA tools. For example, Mend SCA reduces the time that developers need to spend on remediation by 80 percent, which means that developers’ resources are saved for what they do best — creating great applications and getting them to market faster.

3. Talk to the right people

The people who handle this stuff daily — application security teams, developers, and DevOps,  — are your natural starting point. They probably have a keener understanding of security requirements than others in your organization, so their viewpoint is critical. Moreover, developers are increasingly being asked to identify, detect, and remediate these vulnerabilities as part of their role.

However, they might not have a strong voice on where the budget is spent, and others must be convinced of the business case for buying SCA. Who are they, and what can we say to get their backing?

Every organization has many internal stakeholders that are not involved in development and security — such as sales, customer success, R&D, finance, and more — who use the apps and software that developers have created, almost all of which are built with open source components. Additionally, in many cases, external third parties such as customers, are important end users of your apps and software. These users can also provide valuable insight into the benefits they enjoy and the challenges they face when using your apps. So, identify a short list of power users and decision-makers within the organization, who have influence over budgeting decisions. Get their feedback, so you can learn about the state of your application security and you can give them a clearer understanding of why investing in SCA should be a priority.

4. Know what to ask

A consultation is only as thorough as the questions you ask, and different stakeholders will naturally respond better to different questions. 

When you’re consulting technical stakeholders, you should get more granular about the software, components, and dependencies they’re handling. These questions provide a solid basis on which to show that SCA is necessary:

1. Do you use a fixed, unchanging set of open source components and dependencies?
2. Are you fully aware of all the components and dependencies that you use?
3. Are you certain these are all tracked, updated, and fixed to avoid vulnerabilities?
4. Are you confident you’re aware of all security risks associated with the software you use?
5. Are you sure the development and DevOps teams always do scans and updates?
6. Are you confident that you do this due diligence easily and effectively?
7. Can you comfortably scan and fix the volume of code you currently handle?
8. Do you think you can always do so without compromising your productivity?
9. Is the detection and remediation of vulnerabilities currently automated?
10. Is it integrated into their workflow?
11. Are you confident your code base, software, and apps are presently as secure as possible?

Without an SCA tool in place, the chances are that most, if not all of the answers will be “No.” Just one “No” casts doubt on the efficacy of your existing application security measures and shows your decision-makers that you’d benefit from introducing SCA.

When you’re talking with internal and external non-technical stakeholders and customers, aim to get a snapshot of how they feel about the security of your apps and software. Key questions to ask them are:

1. Do you encounter any problems with security on our apps?
2. Do you feel that security issues could compromise our software and apps?
3. Are you concerned about the security of these apps and software?
4. Would you welcome an escalation of security measures?

If the answer to any of these questions is “Yes,” then it’s clear that security concerns others both inside and outside your organization. So, to protect your business, security should be prioritized and addressed, and leading the way with open source security involves implementing SCA.

5. Show the cost of neglect

If decision-makers remain hesitant about buying an SCA tool, you can shift focus from its benefits to the implications of not having one or choosing an inappropriate solution.

Without SCA, the process of detecting, identifying, and remediating vulnerabilities is arduous, and far less thorough than a dedicated tool can deliver. Furthermore, without SCA, you risk shipping applications with less robust security, which can detrimentally affect your code base, your products, your services, your customers, and your reputation as a reliable software and applications provider. It could cost you a lot, financially and reputationally. Ultimately, it’s not good for business.

There are numerous examples of the financial and legal impact of the lack of open source application security. Perhaps one of the most prominent was the Equifax case that occurred in September 2017. The credit agency suffered a security breach that exposed the data of 147 million people. Its failure to protect this information cost $700 million in fines.

Hackers used a well-known vulnerability in the Apache Struts open source component in one of Equifax’s customer web portals. They infiltrated the company’s software and stole data, moving from a point of entry in its web portal to other servers because the systems weren’t adequately segmented from one another. When they found usernames and passwords stored in plain text, they could access further systems. Then they pulled encrypted data from the network.

The initial vulnerability should have been patched. Equifax claimed it wasn’t aware that the vulnerable open source component was being used in the customer portal, but investigations revealed there had been failures in the company’s security process, which included failing to renew an encryption certificate in one of its internal security tools Using the right SCA tool, the vulnerability would have been detected and fixed, and this significant breach wouldn’t have happened.

Building your case

Having taken these steps, you’ll have built a strong narrative about why a budget for SCA is essential. You’ll be able to explain how it can meet the desired business value — over and above the benefits — by filling any capability deficit, and you’ll articulate the value of purchasing SCA.  It’s a lot to take in, so use this checklist to help you cover all the bases. Answer “yes” to each of the following, and you can be sure that you’ve developed a strong case for buying SCA. 

	Yes	No
Outlined the current risk environment for open source apps, using recent research
Understood the function and benefits of modern SCA tools
Identified who to talk to — users, stakeholders, decision-makers
Understood what their concerns and needs are and how they feel about AppSec and SCA (Asked the right questions)
Aligned SCA’s value with these concerns and priorities
Shown how SCA will close any current capability gaps
Explained what could happen if they don’t buy SCA
Shared similar customer success stories
Set out an implementation plan that suits the organization and meets its needs

This week, I’m going to focus on application security. Why? According to Forrester in their State of Application Security 2022 report, software vulnerabilities are the top attack vector in today’s world. Between 70-90 percent of modern applications use open-source software, and depending on how you implement it, open source can be a source of issues. Many penetration testing tools include plug-ins that not only detect libraries you are using, but also identify the security vulnerabilities associated with them.

On a cyber security discussion panel last month I was asked, “When your development team has to get a release out the door in a very short amount of time, why is it that security is typically one of the first processes to be bypassed to help hit the deadline? What should we tell the development team when they ask us to bypass security?”

Great question, because it encompasses the perceived paradox that we cannot be secure and agile. As application security professionals, we need to help change the narrative. If we are consistently holding up the build process, then we will eventually be bypassed. However, if we think outside of the box, we can achieve a win/win. For example, consider leveraging automation to trigger the security scans when code is committed, and do it in a way that is non-blocking. In this way, by the time all of the build processes have completed and the application is ready for QA, the security scans can be delivered simultaneously, and their review should be part of the QA process.

In my previous role as an AppSec architect, my tagline was “Protect and Secure. Reduce Risk. Enable Innovation.” I believe if these concepts are embraced, all three can be achieved to deliver software securely at all times and keep innovation and software delivery on track. Even considering edge cases that may be time sensitive, a collaborative approach can generally lead to a near-term mitigation that still ensures secure delivery of the application. For example, if a vulnerability has been discovered and the release is time sensitive (think log4j), then other mitigation efforts could be used to help reduce the risk of the release. For example, a web application firewall or front-end protection like Cloudflare could be configured to provide near-term mitigation while the software release fix is packaged in the next release.

Finally, when I consider the major challenges of an application security program, I must address the need to identify and approve third-party libraries and applications. Supply chain issues are the number one risk according to CISOs in 2022, and what can be more critical than an application dependency to a compromised third-party component or library? There are several steps to take to improve your third-party risk posture, including leveraging third-party scanning and building an executive reporting process for visibility and support at the decision-maker level of your organization. There are also other technical controls that can be leveraged, such as ensuring your applications leverage a local copy of code libraries versus pointing to an external source that may have been compromised. 

This is just a start, but hopefully it gets you thinking about how to better secure your CI/CD pipeline.