Application security is not a simple binary choice, whereby you either have security or you don't. Application security is more of a sliding scale where providing additional security layers helps reduce the risk of an incident, hopefully to an acceptable level of risk for the organization. Thus, application-security testing reduces risk in applications, but cannot completely eliminate it. Steps can be taken, however, to remove those risks that are easiest to remove and to harden the software in use.
The major motivation for using AST tools is that manual code reviews and traditional test plans are time consuming, and new vulnerabilities are continually being introduced or discovered. In many domains, there are regulatory and compliance directives that mandate the use of AST tools. Moreover--and perhaps most importantly--individuals and groups intent on compromising systems use tools too, and those charged with protecting those systems must keep pace with their adversaries.
This graphic depicts classes or categories of application security testing tools. The boundaries are blurred at times, as particular products can perform elements of multiple categories, but these are roughly the classes of tools within this domain. There is a rough hierarchy in that the tools at the bottom of the pyramid are foundational and as proficiency is gained with them, organizations may look to use some of the more progressive methods higher in the pyramid.
SAST tools can be thought of as white-hat or white-box testing, where the tester knows information about the system or software being tested, including an architecture diagram, access to source code, etc. SAST tools examine source code (at rest) to detect and report weaknesses that can lead to security vulnerabilities.
Source-code analyzers can run on non-compiled code to check for defects such as numerical errors, input validation, race conditions, path traversals, pointers and references, and more. Binary and byte-code analyzers do the same on built and compiled code. Some tools run on source code only, some on compiled code only, and some on both.
Software-governance processes that depend on manual inspection are prone to failure. SCA tools examine software to determine the origins of all components and libraries within the software. These tools are highly effective at identifying and finding vulnerabilities in common and popular components, particularly open-source components. They do not, however, detect vulnerabilities for in-house custom developed components.
SCA tools are most effective in finding common and popular libraries and components, particularly open-source pieces. They work by comparing known modules found in code to a list of known vulnerabilities. The SCA tools find components that have known and documented vulnerabilities and will often advise if components are out of date or have patches available.
To make this comparison, almost all SCA tools use the NIST National Vulnerability Database Common Vulnerabilities and Exposures (CVEs) as a source for known vulnerabilities. Many commercial SCA products also use the VulnDB commercial vulnerability database as a source, as well as some other public and proprietary sources. SCA tools can run on source code, byte code, binary code, or some combination.
Your external support team will work to identify any potential threats or risks to your server, network or files, ensuring your business runs smoothly at all times.
They will also recommend any improvements required to bolster performance and security and, in the event of a cyber attack or disaster, they can backup your data and recover it promptly.
The SQL Slammer worm of 2003 exploited a known vulnerability in a database-management system that had a patch released more than one year before the attack. Although databases are not always considered part of an application, application developers often rely heavily on the database, and applications can often heavily affect databases. Database-security-scanning tools check for updated patches and versions, weak passwords, configuration errors, access control list (ACL) issues, and more. Some tools can mine logs looking for irregular patterns or actions, such as excessive administrative actions.
Database scanners generally run on the static data that is at rest while the database-management system is operating. Some scanners can monitor data that is in transit.
Hybrid approaches have been available for a long time, but more recently have been categorized and discussed using the term IAST. IAST tools use a combination of static and dynamic analysis techniques. They can test whether known vulnerabilities in code are actually exploitable in the running application.
IAST tools use knowledge of application flow and data flow to create advanced attack scenarios and use dynamic analysis results recursively: as a dynamic scan is being performed, the tool will learn things about the application based on how it responds to test cases. Some tools will use this knowledge to create additional test cases, which then could yield more knowledge for more test cases and so on. IAST tools are adept at reducing the number of false positives, and work well in Agile and DevOps environments where traditional stand-alone DAST and SAST tools can be too time intensive for the development cycle.
The Open Web Application Security Project (OWASP) listed the top 10 mobile risks in 2016 as
1. improper platform usage
2. insecure data storage
3. insecure communication
4. insecure authentication
5. insufficient cryptography
6. insecure authorization
7. client code quality
8. code tampering
9. reverse engineering
10. extraneous functionality
As the name suggests, with ASTaaS, you pay someone to perform security testing on your application. The service will usually be a combination of static and dynamic analysis, penetration testing, testing of application programming interfaces (APIs), risk assessments, and more. ASTaaS can be used on traditional applications, especially mobile and web apps.
Different AST tools will have different findings, so correlation tools correlate and analyze results from different AST tools and help with validation and prioritization of findings, including remediation workflows. Whereas some correlation tools include code scanners, they are useful mainly for importing findings from other tools.
ASTO integrates security tooling across a software development lifecycle (SDLC). While the term ASTO is newly coined by Gartner since this is an emerging field, there are tools that have been doing ASTO already, mainly those created by correlation-tool vendors. The idea of ASTO is to have central, coordinated management and reporting of all the different AST tools running in an ecosystem. It is still too early to know if the term and product lines will endure, but as automated testing becomes more ubiquitous, ASTO does fill a need.
There are many factors to consider when selecting from among these different types of AST tools. If you are wondering how to begin, the biggest decision you will make is to get started by beginning using the tools. According to a 2013 Microsoft security study, 76 percent of U.S. developers use no secure application-program process and more than 40 percent of software developers globally said that security wasn't a top priority for them. Our strongest recommendation is that you exclude yourself from these percentages.