Posted on

The Battle Between Linters, Scanners, and Data Flow Analysis

When it comes to security tools, you're typically balancing two things: how much time it takes for a tool to run to get deeper results vs. the quality of results returned.

As you might expect, faster tools scan just the source code in a single repo (without looking in the open-source libraries and SDK used) and may detect easy-to-find vulnerabilities. In contrast, tools that give better results and can find more challenging vulnerabilities with fewer false positives require more time to complete their scans.

Posted on

How to Get Instant Java Web Security Vulnerability Alerts in GitHub

If you're building Java web applications or Java Web API's and you want to do your own security testing, wouldn't you rather not run a scanner and wait forever for a PDF report full of all false positives? And wouldn't it be great if those vulnerabilities showed up automatically in GitHub Issues? 

We're going to set up automatic and extremely powerful security testing using a tool called Contrast Community Edition, which uses the latest IAST (Interactive Application Security Testing) technology. My company made CE free and full-strength for everyone in order to bring great security to all the developers in the world that can't afford commercial static and dynamic scanners.

Posted on

9 Product Flavors That Fit the Security Needs of the Entire Software Lifecycle

Security needs to be adopted at every stage of the SDLC

Speed to market has been everything in the software development world. But, over time, we’ve discovered that speed alone cannot be the end all be all. The majority of data breaches have to do with web application security vulnerabilities; and therefore, security must become part of the software development equation.

The problem is that most organizations approach security at the end of the software development lifecycle, when it’s often too late or too complicated to fix vulnerabilities. To be effective, security must be integrated throughout each stage of the entire software development lifecycle.

Posted on

Why You Need Static and Dynamic Application Security Testing in Development Workflows

DevOps is a quickly growing practice for companies in almost every market. With the influx of cyberattacks over the past decade, security has slowly crept forward in the SDLC to the point where we’re now hearing the term DevSecOps in developer circles.

To keep things tidy and help developers manage additional security responsibilities, tools for static and dynamic application security testing (SAST and DAST) have made their way into the fray. In this post, we’ll explain what SAST and DAST are, how they fit into developers’ workflows, and when they should be used.

Posted on

Most Effective AppSec Tools and Techniques

To understand the current and future state of application security, we obtained insights from five IT executives. We asked them, “What are the most effective application security techniques and tools?” Here’s what they told us:

  • Runtime Application Self Protection (RASP) is effective because it actually protects vulnerabilities through automatic remediation without code changes. This leverages insights into applications, applying the right protection where and when it matters.
  • Analyzer engines/scanners tools are continuous watchdogs for production APIs and production applications. We need to always be analyzing. Netflix does 300 production changes per day. They need to constantly look in production. Get away from dependence on operating system agents, proxies, and firewalls. They are non-scalable and are not effective. Automate at scale and look for anomalies. Humans for risk management and policy enforcement (HIPPA, SOX, etc.).
  • There is no single set of effective techniques and tools. As with any field, it is imperative to avoid putting all your eggs into one “technique or tool” basket. You’ll just create a false sense of security. A good security strategy involves looking for vulnerabilities from multiple different angles and handling the risk. Remember the majority of security breaches are done by employees or recent ex-employees, not hackers (source: 2018 IT Risks report). That means effective modeling of your release process and setting up a bulletproof role-based access control scheme is very important for controlling these internal threats.
  • Many of the techniques mandated by PCI are the foundations of a good security posture — regular vulnerability scans, penetration testing, risk assessments, and ethical hacking go a long way. During these processes, open-source tools like Nmap, Wireshark, P0f and Argus can help.
  • Technologies that analyze apps throughout the lifecycle from the beginning to end.
    Three technologies: 1) SAST (static application analysis) analyzes applications for the existence of vulnerabilities, 2) DAST (dynamic application security testing)  analyses application behavior at runtime, and 3) SCA (static code analysis) detects open source components with vulnerabilities. Fewer than 50% of enterprises adopt these technologies. They keep buying firewalls. Those that have invested are not testing the entire portfolio of applications, just one or two, so most vulnerabilities are not fixed. I have not seen any company investing enough to test all of its applications. They keep doing what they’ve been doing for years — buying firewalls. The government is doing nothing to stop the attacks. 140 million records of Americans are available to hackers stealing money and performing malicious actions. This is a direct result of our negligence and our stupidity of not protecting applications.

Here’s who shared their insights:

Posted on

The Value of Security Testing in QA

Over in the TechWell Hub, I was recently asked by a fellow community member, "Is there value in having traditional testers do security testing in addition to the testing taking place from our security group?" I thought it was a great question, and it deserves a more detailed response.

For many organizations, traditional software and testing groups are separated from the IT security group. The first is just concerned with functionality, while the latter cares only about security. In many cases this results in adversarial relationships, which almost always leads to some challenges for software development teams:

Posted on

DevSecOps: Securing Software in a DevOps World

This article is featured in the new DZone Guide to DevOps: Implementing Cultural Change. Get your free copy for insightful articles, industry stats, and more!

The practice of improving and ensuring the security of software is generally referred to as (the field of) application security, or "AppSec" for short. In a traditional waterfall system development lifecycle (SDLC), AppSec was often an afterthought, with someone (a penetration tester) being hired to come in just before release to perform last-minute security testing, or not at all. Slowly, many development shops started adding more AppSec activities such as secure code reviews, providing secure coding guidance or standards, giving developers security tools, and introducing many other great ideas that improved the overall security of the end product. Some companies even went so far as to create their own team dedicated to application security. However, there is currently no agreed-upon standardization on what defines a complete AppSec program, nor a definition of when someone can say that "the job is done" or that they have done "enough" in regard to the security of software. The line seems to vary greatly from team to team, business to government, and country to country, which makes it a difficult thing to measure.