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 tasks to the Issue Tracker.

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

Steps or additional controls added to a task’s solution when certain conditions match a project’s settings. Also known as a Task 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 problems, tasks, 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 task created by a user of the system. The task can be assigned to projects and maintained similar to the official or default tasks.

A task originally developed by Security Compass and kept updated through product updates. After each product update, a default task is updated to the latest available content. However, any changes that have been made to the task, 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 task.

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 task is a task that is managed by the SD Elements content library. See Library tasks 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 Task, Problem, Amendment, 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 task. See Default task 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 tasks, 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 task is almost identical to a normal task 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 tasks in the SD Elements project.

A verification tool indicates whether a task 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 task. Evidence of a vulnerability is proof that the corresponding task is not fully implemented and therefore cannot be verified. Alternatively, the absence of a vulnerabilty can imply, in some cases, that the task is indeed verified to be fully implemented.

SDLC is an acronym for Software Development Lifecycle.

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

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

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

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