The representation of a real-world application, such as a mobile application, web application, web service, or rich client.

A bug tracker or ticketing system that is used primarily by software developers to track sprint and project work. Examples: JIRA, Azure DevOps, Rally, and so on.

A system-wide configuration setup for a specific Issue Tracker service. A connector is used to create an Issue Tracker Connection to sync Countermeasures to the Issue Tracker.

A project-specific integration based on an Issue Tracker Connector. The connection syncs SD Elements project Countermeasures to a specified Issue Tracker project.

Steps or additional controls added to a Countermeasure’s solution when certain conditions match a project’s settings. Also known as a Countermeasure amendment.

The first project created for an application. Also known as a Root project.

A Business unit models a division in your business. For example, a Web Application Team, Consumer Financial Division, and so on. See Business units for more information.

A term given to Weaknesses, Countermeasures, Additional Requirements, How-tos, glossary and other similar artifacts. Generally, most content can be customized to meet organization-specific needs.

A customization allowing additional information to be tracked on applications and projects. See Application attributes and Project attributes for more information.

A Countermeasure created by a user of the system. The Countermeasure can be assigned to projects and maintained similar to the official or default Countermeasures.

A Countermeasure originally developed by Security Compass and kept updated through product updates. After each product update, a default Countermeasure is updated to the latest available content. However, any changes that have been made to the Countermeasure, such to "priority" and "phase", will continue to override the underlying values.

Dynamic Application Security Testing (DAST). DAST tools examine applications for security weaknesses while an application is running. DAST is often called "black-box testing" since it tests the behavior of an application without access to internals (such as source code, byte code).

Roles for what a user can do in the application. For example, create projects, customize content, and so on. Manage these roles for individual users through the Manage Users→Users page.

Contextual advice on how to implement a certain requirement or Countermeasure.

Interactive Application Security Testing (IAST). IAST tools employ DAST and SAST methods to examine applications for security weaknesses. Combining both strategies can help eliminate false positives and false negatives.

A Library Countermeasure is a Countermeasure that is managed by the SD Elements content library. See Library Countermeasures for more information. It is normally added to a project when its Match conditions are satisfied by the survey. However, they can also be manually added to a project if needed.

A set of rules that determine whether a Countermeasure, Weakness, Additional Requirement, or How-to is relevant to a project.

A new release is a new project that copies the same project settings as your current project. The intent of the "new release" function is to model the deltas between projects. See Create a release project for more information.

This is also known as a _Default Countermeasure. See Default Countermeasure for more information.

A stage in the process of completing a project. By default, SD Elements tracks four phases: Requirements, Architecture and Design, Development, and Testing.

A security weakness or business-related breakdown that may affect a project given certain conditions (for instance, SQL Injection, Buffer Overflow, missing authentication).

A project profile is a way to automatically select common project settings for a given application type. For example, "Generic Web Applications" tend to have SQL databases, use cookies for session management, and so on. See Profiles for more information.

A single release of an Application.

Roles for what you can do in an project: change project settings, add notes to Countermeasures, and so on. The roles may be different for an individual user in each project. These roles are assigned to users and groups at the project level.

A project specific Countermeasure is almost identical to a normal Countermeasure but with the following distinctions:

Settings or attributes that can influence the risk profile or business context for a work effort or project, as in "Uses a database" or "Subject to the laws of California". This is also known as a Project survey. See Project survey for more information.

Settings or attributes that can influence the risk profile or business context for a work effort or project, as in "Uses a database" or "Subject to the laws of California". This is also known as Project settings. See Project survey for more information.

The first project created for an application.

A form of logic used to decide when Content is applicable to a project. A rule is composed of boolean operators (AND, OR, NOT) that influence when content is included or excluded in a project or release.

Static Application Security Testing (SAST). SAST tools search an application’s internals (source code or byte code) for security weaknesses. They do not require an application to be running to perform an evaluation. SAST is often called "white-box testing".

A system-wide configuration for a specific Verification service. A connector is used to create a Verification connection.

A project-specific integration based on a Verification connector. The connection imports vulnerability details and updates the verification details of Countermeasures in the SD Elements project.

A verification tool indicates whether a Countermeasure is implemented according to its guidance. One example is a source code scanner: in certain cases it can be used to identify vulnerabilities in software that map to a Countermeasure. Evidence of a vulnerability is proof that the corresponding Countermeasure is not fully implemented and therefore cannot be verified. Alternatively, the absence of a vulnerabilty can imply, in some cases, that the Countermeasure is indeed verified to be fully implemented.

SDLC is an acronym for Software Development Lifecycle.

A Countermeasure is an individual unit of work in SD Elements. A Countermeasure represents either a prescriptive step to prevent a Weakness (a potential security vulnerability, for example), or a method to test whether that Weakness exists. Each Countermeasure has a status representing whether or not it is complete, a priority, and other Countermeasure-specific properties.

For example, "T6: Implement account lockout or authentication throttling" is a Countermeasure to prevent brute-force authentication attacks.

Steps or additional controls added to a Countermeasure’s solution when certain conditions match a project’s settings. Also known as Additional requirement.

Indicates the verification status of a Countermeasure, as indicated by an automated scanning solution or manual verification. The verification section provides assurance that a Countermeasure has actually been completed. See Expanded Countermeasure detail for more information.