AppSec Glossary

ASPM

Application security posture management (ASPM) automates the identification of software assets as well as the tracking and scheduling of all application security tools and processes. ASPM approach offers a systematic process to accomplish maturity in application security. ASPM is used to gain visibility on application assets, regardless of their infrastructure. It simplifies complex workflows while collecting mission critical data, and governing a sustainable, unified software security process across the organization.

Bot Mitigation

Bot Mitigation refers to efforts designed to identify and stop non-human based activity in web applications. While some bots are considered “good” and may be in the interest of the web developer like various SEO bots, some bots and botnets are being used by malicious actors to perform malicious activities like scraping data from web applications, performing DoS (Denial of Service) attacks, or automated abuse of resources for spam attacks, sextortion, or crypto-currency mining. Examples for bot mitigation include client behaviour analysis, bots requests signing, rate limitation, and CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) challenges.

Broken Access Control

Broken Access Control (BAC) is the way in which attackers bypass a web application’s access control, also known as authorization, to resources and functions, granting authorization to some users and denying it to others. Common examples of broken access control include insecure user ID’s, client-side caching, forced browsing to authenticated pages, elevation of privilege, and more. The ramifications of BAC range from viewing unauthorized content to harmful application takeover.

BAC was listed as the #1 most critical security risk to web applications in the 2021 OWASP Top Ten.

Bug Bounty

Security Bug Bounty (sometimes referred to simply as Bug Bounty or BB) refers to programs that allow responsible disclosure of security vulnerabilities, most times in exchange for a monetary reward or acknowledgment in the form of reputation. Security bug bounty programs can be public (open for anyone to submit a security report of a finding) or private (restricted for specific security researchers or invite-based upon reporting). Usually a security bug bounty program is private or public according to the availability of resources of the maintaining security team. Security bug bounty programs can be externally managed by a bug bounty management platform like HackerOne or BugCrowd. Maintaining a bug bounty program is considered best practice as it allows to extend the application penetration testing resources with real-world researchers, while the maintainer determines the security attention by determining the security bug bounty policy and rewards.

CI/CD

CI/CD is the combination of continuous integration and continuous delivery/continuous deployment. CI/CD pipeline refers to the automated process which allows for incremental code changes to be quickly and adequately delivered to production. This process enables developers to continuously integrate service or feature changes and for operation teams to couple with delivering the needed compliance and security standards.

DAST

Automatic Dynamic Application Security Testing (DAST) refers to security tests that are performed at the application level by building/executing the application and reviewing the application build/runtime environments. The build/runtime can be tested in various ways such as reviewing the resources that the application is accessing in build/runtime and verifying if it is compliant to a given policy, or appropriate to the application declarations.  Another way to dynamically test the application is by fuzzy testing - running the application with unexpected inputs and known malicious payloads while reviewing the application behaviour and output to assess if it is vulnerable.

Automated DAST can be used as an automotive security tool as part of the CI pipeline as well as continuous automation over production environments.

IAST

Interactive Application Security Testing (IAST) examines code for security vulnerabilities by continuously analyzing all application interactions initiated by manual tests, automated tests, or a combination of both, all while the application is running. This technology detects vulnerabilities and sends a report in real-time so it does not add extra time to your CI/CD pipeline. The core of an IAST tool is sensor modules and software libraries included in the application code. These sensor modules keep track of application behavior while the interactive tests run.

IDOR

Insecure direct object reference occurs when a software uses a user-provided reference key without properly checking permissions. For example, a system that directly reads an “account id” reference from a logged-on user, without making sure that the user is allowed to access the specified account, will be vulnerable to IDOR. Common methods to avoid such issues include implementing authorization checks, or mapping the reference keys (per session, or per user, on the server side), so that the keys used by the user represent a temporary indirect reference.

OWASP Top 10

The Open Web Application Security Project (OWASP) is an open group dedicated to Web Application Security, as part of the research of the project the group publishes a list of the most common web application security vulnerabilities. This list is a basic resource for outlining the basic risks web applications are exposed to, as well as to review trends in common vulnerabilities and attacks over time.

Penetration test

Penetration test is a dedicated custom set of automatic and manual tests performed by a security expert (the Penetration Tester) built for a specific ad hoc application security testing, usually after the application is fully developed. The penetration test is designed to check the security maturity of the system and to discover weaknesses and vulnerabilities that require mitigation. Usually the penetration test will result in a PT report detailing the weaknesses and vulnerabilities discovered, along with risk analysis of each finding and recommendation for mitigation. Penetration tests can be white box (where the penetration tester has access to internal data like the architecture design or source code of the application) or black box (where the penetration tester has no internal data of the application). Some standards (like PCI compliance standard) define requirements for the penetration tester qualifications and other penetration testing methodologies standards and requirements.

RCE

Remote code execution (RCE) is the ability of an attacker to remotely execute arbitrary code on the application server and access its resources. Remote code execution can stem from a variety of defects including memory corruption, missing input validation, and failure to restrict access to sensitive functions.

Red Team

Red team is a common name to describe an external security exercise for breaching organization security measures with no internal knowledge and no specific application scope. The concept is that the red team simulates a real threat actor targeting the organization, from determining the attack surface and selecting the attack vector, to the proof of concept of sensitive data access/leakage or disruption of business processes.

Runtime protection and detection

Runtime protection and detection refers to all efforts for the detection of malicious activities and protection of the organization resources from malicious activities. Malicious activities can be attempts to cause harm to the organization (e.g. Denial of Service, breaching systems and data harvesting), or abuse of the application resources to perform fraud, spam, crypto-currency mining, etc.

SAST

Automated Static Application Security Testing are automation tests that review the code base for vulnerabilities, usually as part of the CI pipeline or locally via an IDE integration of a SAST tool. For example, base code is checked for mishandling of user input that could allow template injection or sql query injection. SAST tools may also suggest the developer mitigation solution like deserializing untrusted user input.

SBOM

Software Bill of Materials refers to a complete structured list of components, libraries, and modules that are required to build a given piece of software and the supply chain relationships between them. It also catalogs the versions, upgrades, known vulnerabilities, and dependencies in the components.

A May 2021 Executive Order issued by the White House requires software vendors who work with the federal government to provide SBOMs for their products.

SCA

Automated Software Composition Analysis (SCA) includes scanning and evaluating code dependencies (usually open-source) for known vulnerabilities and licensing.

This process is applicable to composers and dependency managers such as Docker Compose, Maven, NPM Bazel and pip.


SDLC & SDLC touch points

Secure development lifecycle is a discipline that focuses on properly conducting security activities at key stages of development.

SSRF

Server Side Request Forgery is a server attack that refers to the ability of an attacker to perform network calls originating from the application server. Usually such attacks can result in restricted internal network resources access, not exposed to public networks, or the exposure of internal information disclosure as part of the server-request, like a server authorization token. As more and more applications move to cloud-based architecture the SSRF attacks are becoming more generic, and usually impose a high or critical security risk.

Threat modeling

A methodology for reviewing and assessing security threats in an ordered fashion avoiding security “blind spots”, usually performed as part of the design phase, but can be performed at a later stage. Threat models assist in both the discovery of unnoticed security risks and in reviewing the known issues mitigation plans. Threat modeling should be performed at an early stage of the development process, usually as part of the architecture design review phase.

Examples of threat modeling methodologies: STRIDE, attack trees, CIA.


WaaP

Web App and API Protection (WaaP) is a collective name for solutions that offer both web application and API protection from various attack vectors by combining bot detection and mitigation, and inspection of API requests. An example is inspecting the parameters the client sends in the request and identifying invalid/non-legitimate parameters and blocking such invalid requests from getting to the application service.

Weaknesses & Vulnerabilities

Weaknesses and vulnerabilities are both states that indicate security risks. While weakness refers to an application error or bug, it may escalate to a vulnerability in cases where it can be exploited to perform a malicious action. The difference between a weakness and a vulnerability is the availability of a specific payload allowing it to be exploited. Once an exploit is available it is considered a confirmed vulnerability and as such it holds greater risk to the application security.

XSS

Cross-Site-Scripting (XSS) is a client attack that manipulates an Web client (for example, a web browser) to run a malicious customized script leveraging access to resources available by the attacked web application, like the ability to perform an API call as an authenticated user, or change any client resource in the web page document to manipulate the user to perform unwanted actions by a seemingly trusted source.

Back to topBack to top
Application Security Posture Management

AppSec, but so much

Reclaim AppSec