Invicti Insights: Squashing AppSec urban myths and legends

Urban myths in application security (AppSec) spread just like any other common legend would – through fear of the unknown. Often propagated through forums, social media, and even word-of-mouth, these urban legends about AppSec create a false sense of security – or misdirect legitimate concerns about security – which can lead to inadequate protection against threats and potential exploits. 

Urban legends in AppSec can span a variety of topics, like the myth that a password that’s hard to remember for humans is also hard to crack for machines; in reality, superficial complexity does not always guarantee security and can potentially instill a false sense of safety. Open-source software is rife with legends too, with many developers and engineers assuming that simply because there are more eyes on open-source code, that makes it more secure by default – which we know isn’t the case, considering a 742% year-over-year increase in open-source software supply chain attacks in 2022. 

These and other urban legends in AppSec are dangerous because they can lead to poor security practices or missed opportunities when it comes to reducing your threat exposure. Taking myths to heart can leave your web applications and other critical software assets vulnerable to attacks by threat actors who are counting on precisely those misconceptions. That’s why it’s critical for developers and security professionals alike to stay informed about the latest trends and best practices while also always questioning common beliefs to ensure they’re based on fact, not myth. 

In the previous edition of our Invicti Insights series, we delved deep into how leadership can help get the Board on board with cybersecurity. For this next installment, we’re shifting focus to urban myths that can lurk in the shadows and undermine sound security judgment. Read on for insights from Invicti’s Director of Product Management, Jonny Stewart, and Director of Product Marketing, Patrick Vandenberg, as they share their experiences confronting myths in software security – and get tips on how you can help squash these familiar fallacies before they result in very real problems. 

What, in your opinion, is one of the biggest and most popular myths about cybersecurity?

Jonny Stewart: There are two myths in cybersecurity that, for me, are some of the biggest. The first is that AppSec programs are always a dumpster fire waiting for the next big risk to come down the pipe. Situations like that do occur where vulnerabilities come out and a couple of months later a breach happens, such as with the 2017 Apache Struts incident. However, according to Verizon’s 2022 Data Breach Investigations Report (DBIR), most malicious actions are financially motivated. So if an organization has an active AppSec program, the time required to breach that organization likely outweighs the potential financial gain to the attacker, and so the malicious actor moves on.

 

Another common myth is that networks are the primary attack surface, when in reality it is web applications today. Before COVID-19 and the shift to remote work, data was mainly contained within the corporate network, where employees would physically travel to the network and work within it to share information. Now that there are more remote work environments, data is traveling more frequently over external networks and the cloud. Breaches where remote work is a factor tend to cost $1 million higher than those where it isn’t, with the average cost of a breach in the United States racking up $9.44 million for organizations. And with 45% of breaches occurring in the cloud in 2022, mature security programs that discover and scan your entire attack surface are key. 

Patrick Vandenberg: One of the biggest myths I’ve seen specifically in application security (AppSec) is that because of the rapid adoption of developer-centric methods such as static security testing (SAST) and software composition analysis (SCA), there is less of a need for dynamic application security testing (DAST). DAST has been a main focus for the security industry for a while because we have applications that we need to test dynamically before deploying them, and that has progressed to an audit-style cadence for dynamic testing of web applications. As more mature application security programs adopt SAST and SCA to scale testing across development and enable more effective collaboration between development and security, it still doesn’t come together without DAST.

 

AppSec today presents a much larger security footprint than many have the capacity to focus on; while network or security operations are viewed as a more critical aspect of security to some, there is so much code being produced every single day that businesses are seeing more potential exposure than ever. The latest Verizon DBIR shows that 70% of incidents started with web applications as the initial attack vector. The risk landscape is large for organizations with a lot of applications, and the complexity of the IT environment and landscape means you need to have full visibility and monitoring of where breach activity might take place, or you’re bound to miss some critical security flaws. That’s where automated DAST tools can shine, pinpointing vulnerabilities that might otherwise go unnoticed. Because DAST uses web crawling technology to map out all of an application’s resources, it can more readily cover the real web footprint of the app in ways that SAST simply can’t do alone. 

Why do you think so many organizations believe the myth that if part of their software development lifecycle is secure, the whole thing is?

Jonny Stewart: Most of the belief in the myth is tradition, a lack of cybersecurity budget, and the gray lines between developer and security team responsibility. As a developer, the ownership of an application tends to end once it has shipped. In extreme cases, developers consider that application “legacy” on day two after shipping. Therefore, it is important to assign ownership and tooling to monitor those production applications until the day they are retired and taken completely offline.

 

Shifting left is not enough on its own. Shifting left helps find and fix vulnerabilities early in the software development lifecycle (SDLC), but it does not help when a new vulnerability is announced or libraries become stale in production. An organization needs to have the experience and tooling available to monitor all their applications continuously in an automated fashion.

Patrick Vandenberg: Just because you’ve deployed SAST and have shifted security left in the SDLC doesn’t mean you have solved your application security challenges. In fact, there are dangerous gaps in security coverage without DAST in place. Many organizations don’t fully understand how to approach vulnerability types and where or how they need to be identified.

 

You must have SAST, SCA, and DAST working together to improve coverage and find more vulnerabilities. Because SAST doesn’t test for some vulnerabilities, you need DAST running consistent, automated checks to identify those flaws. DAST is the only way to look at your attack surface the same way that an attacker does, and the more you discover, the more you see the need for these various scanning methodologies that cover the entire SDLC. Additionally, testing coverage from DAST becomes the only option for third-party apps where we don’t have access to code, so a strategy to shift right as well as left gets us closer to a secure SDLC.

There’s an urban myth in cybersecurity that it takes a ton of knowledge and experience to become a hacker or security professional – what is the reality of that situation?

Jonny Stewart: That is true for those who want to become a top pentester. The best ethical hackers or pentesters have years of experience and tons of knowledge. The same is true for the top unethical or malicious hackers, but this only stands true when the target to be hacked is a difficult one or we are looking for novel approaches. It is easy to target older vulnerabilities (those with published exploits) in, say, Metasploit or by following published examples. This is the unethical version of following an article on Stack Overflow! It drastically reduces the time and experience required and is why it is so important to patch old technologies, as these are the ones with published exploits that become simpler and simpler for new unethical hackers, or even kids starting out, to follow.

 

Even easier than that, and taking no experience or skill, many unethical hackers with years of knowledge and experience are available to hire in a couple of minutes. Simply download a Tor browser and jump on a forum or a chat room on the dark web, and hire someone or a team to carry out the breach on your behalf. These scenarios become less and less dangerous when you consistently discover your apps and APIs, scanning them and keeping them up to date – a common takeaway for squashing urban myths about AppSec.

Patrick Vandenberg: This is a great conversation, and the myth can go either way. Hackers of all levels are able to find the knowledge they need very quickly, so it truly depends on how motivated they are. Lower experienced attackers can be effective by leveraging the wide array of ready malicious tools and services. Certainly, when anyone becomes more experienced in their skillset, malicious or otherwise, they become more impactful. This is true for attackers as well. 

When it comes to working in application security, historically, it requires a combination of two technical areas of expertise: security and development. That can limit the talent pool. Highly skilled DevSecOps professionals are costly and hard to come by, so when you’re looking for both sets of abilities in one person, it can be a rare find.

 

Taking Jonny’s framework of layers of experience, though, there are certainly developers who have the right levels of security knowledge and progress to become security mavens for their companies. The same goes for the security side of the aisle; if security professionals learn the development tools and processes, they can become advocates for those necessities. But to reach the tip of that pyramid, where you have all the knowledge it takes to become a high-level professional in cybersecurity who can cover both sides, you need the capacity to learn both the development process and the security process. In this case, it does require a lot to be proficient in application security.

The urban myth around open-source code is that it’s secure just because there are more eyes on it – what is the reality about open-source code security and what is the most important thing organizations can do to squash that myth?

Jonny Stewart: Unfortunately, without professionals working on open-source libraries, these projects can become neglected and often aren’t scanned. Open-source libraries become less secure when they are not fashionable and supported by the developer community. Vendors, on the other hand, have a vested interest in keeping their software patched because nobody truly “owns” that responsibility in open source.

 

It doesn’t make sense to invest one of the world’s limited resources (developers) into recreating something fundamental that already exists. Your developers should be working on adding business value, not recreating code. If you force them down such a path, in my opinion, most developers who use open source will look for an organization that allows them to use it. To make security seamless when using open-source components, you need to have monitoring in place for them within your AppSec program, scanning early in the SDLC and also in production.

 

Organizations can also help by allowing developers to contribute to open source. Where you use it, improve it. It’s the age-old Boy Scout rule of “leave the place cleaner than you found it.” Focus on discovering the use of open-source libraries both internally and externally, per the Biden Administration’s Executive Order. Start with libraries that are actually used in your web applications to shorten your list of items for remediation and reduce the noise in your findings.

Patrick Vandenberg: I think it can be very much the opposite – the broader the scope of any scenario and the more unregulated something is, the more fragmented it becomes. And that is quite true with open-source code. While there is tremendous benefit to security-conscious movements to improve open-source code as a whole, much like application security in general, the security of applications is in a constant chase with their functionality. The result is less control because fewer people are monitoring the security of that code or component. There is certainly some benefit to this type of exposure in the world of open source, as developers have access to the things they need to get work done quickly, but it presents a problem where security is secondary as developers add to the sprawl of that code. 

 

Even when a code base achieves a state of no vulnerabilities, subsequent versions can introduce more flaws and more issues. When you apply software composition analysis (SCA), you can cover a distribution package that is then checked for vulnerabilities and remediated – only to discover a subsequent version rife with vulnerabilities. Some security programs will guide developers to revert to a prior version that’s cleaner, which ultimately proves the myth wrong: just because there are more eyes on it doesn’t mean it’s more secure or up-to-date. 

What are some tips you have for ways that leadership and management can help dispel urban myths about security in their own organizations?

Jonny Stewart: Leadership and management can help by setting the example that delivering business value securely is the company culture. For example, work on elevating the CISO in the organization as much as possible. Engineering leaders should set rules that it is never acceptable to ship with critical or high vulnerabilities – even if that delays delivering business results. 

 

The cost of delay can be weighed against the cost of a breach and the potential brand damage. Product leaders must ensure that security requirements are always on top of the non-functional requirements. Lastly, leadership should free up time and budget to implement security where it is lacking, including time set aside for employees to learn and share, becoming security champions within their teams, and getting rewarded for doing so.

Patrick Vandenberg: Ideally, you have a Chief Information Security Officer (CISO) who understands security inside and out, and they’re able to connect with other critical roles like the Chief Product Officer (CPO) or SVP of Research and Development to more efficiently align on business priorities for the entire organization. But not every business has a CISO – 45% of companies don’t have someone in this position, in fact, and that lack of security authority makes it more difficult to adopt security best practices all around without the necessary knowledge and guidance. For the organizations that do have CISOs, they are often so focused on real-time security operations and managing the dozens of security tools under their belt that it’s too difficult for them to ensure security efforts are rolling out through the rest of the organization. 

 

A CISO will not only drive the selection and deployment of many (in many cases dozens) of tools but also drive the adoption of tools, training, and the culture of security in an organization. Security can’t be effective without the partnership of all employees understanding and being part of the solution, much like AppSec teams rely on a tight collaboration with development. 

One urban legend in AppSec says that small to medium-sized businesses (SMBs) are rarely targets for attacks – in reality, size doesn’t matter when it comes to security risk. Their data can be just as valuable to the bad guys. Should SMBs take the same steps as large organizations when approaching AppSec?

Jonny Stewart: Size doesn’t matter for attacks, but the motivation for unethical attackers does change. When a small to medium-sized business is attacked, it is generally for money; according to the Verizon DBIR, 96% of breaches are motivated by financial or personal gain. On the other hand, larger organizations can see attacks for financial or personal gain but also breaches that stem from disagreements, protests, curiosity, and even just an attack carried out for fun. 

 

SMBs should avoid being the easiest target for financial or personal gain, and then the attacker will move on. Threat actors have limited time and resources too, so they spend the most time and effort where they can get a return on their investment. As an SMB, the goal should be to have a cybersecurity program running within your budget that protects your business to the point that spending time and investment on a breach outweighs any potential gain for the bad guys.

Patrick Vandenberg: Risk is really an equation of value and exposure. If a smaller business appears to be of “lower value” to an attacker, then there is truth behind this urban legend. Unless the attack is state-sponsored, malicious activity is always financially driven. So, if the organization is too small, then it falls below the ROI threshold for attackers. They run a business just like anyone might – they lease and leverage codebases and tools to be more efficient, come in on Mondays and take weekends off after triggering attacks on Friday afternoon (not exclusively of course, but this is a typical behavior). They’re going to invest in targets with the most value. 

 

All of that said, you can counter this myth in a situation where a medium or small-sized digital bank, for example, doesn’t have a lot of employees but does have a lot of resources or value. In this example, you can categorize that bank as having more than enough risk exposure placing them in the crosshairs as a potential target. Organizational size is an important element when we’re considering security risk, but ultimately the crucial factor is the recognized value of the target by the attacker.

Missed the first edition of our Invicti Insights series? Check it out here, and stay tuned for the next one!