DevOps

DevSecOps Glossary

A glossary covering the most important DevSecOps terms – from Agile and CI/CD to vulnerability scanning and threat modeling.

XALT favicon: white XALT logo on black background with digital light effects.TEAM XALTAtlassian Platinum Partner·1 March 2023·9 min
DevSecOps glossary

In recent years, DevSecOps has established itself as an important approach to software development, with security taking centre stage throughout the entire software development lifecycle. DevSecOps combines development, security, and operations into a unified and collaborative approach that helps teams develop secure software faster and more efficiently. As in many other fields, DevSecOps has its own terminology and a number of acronyms that can be difficult for beginners to grasp. In this article, we provide a comprehensive glossary of DevSecOps terms and definitions to help developers, security experts, and operations teams understand and communicate effectively in this rapidly evolving field.

To find out exactly what DevSecOps is about and why this approach is increasingly being used, read on: The essential role of security in DevOps

Table of Contents

show

  • About the glossary

About the glossary

This glossary compiles a list of common terms and concepts used in the context of DevSecOps, including Agile, Continuous Integration, Continuous Delivery, DevOps, security, vulnerabilities, penetration testing, and more. Understanding these terms is essential for anyone working in the DevSecOps space or looking to learn more about this important area of software development and security.

Agile:

A set of principles and practices for software development that prioritise flexibility, adaptability, and continuous improvement. Agile practices are frequently used in DevSecOps to enable the rapid deployment of software updates and facilitate collaboration between development and security teams.

API security:

The practice of securing Application Programming Interfaces (APIs). APIs enable different systems and applications to communicate with each other. API security is a key concern for DevSecOps, as APIs often expose sensitive data and functions to external systems. If APIs are not adequately secured, sensitive data can leak out. APIs can, for example, be secured using OAuth tokens and TLS encryption.

Bug:

A defect or error in a system or application that leads to unexpected or undesirable behaviour. Bugs can range from minor issues that do not significantly affect a system's functionality to major security vulnerabilities that can be exploited by attackers. DevSecOps fixes security vulnerabilities (critical issues) before new features are completed.

Cloud:

A network of servers, storage, and other resources is made available over the Internet, allowing users to access and use them on demand. Clouds can be public, meaning they are operated by a third party and accessible to a range of potential customers, or private, meaning they are operated by a company and accessible only to that company.

Cloud security:

The practice of securing systems, applications, and data in cloud computing environments. Cloud security is a central concern for DevSecOps and involves the use of tools and practices such as encryption, access control, and network segmentation to secure cloud environments.

Code review:

A process in which one or more team members review code changes before they are merged into the main branch. Code reviews, regression tests, and test coverage help ensure that code changes are of high quality, coding standards are adhered to, and code readability is maintained.

Compliance:

Adherence to legal standards and guidelines regarding security, data protection, and other areas. In DevSecOps, compliance is often a central concern, and practices and tools are introduced to ensure that systems and applications meet the relevant regulations.

Configuration management:

The management, organisation, and control of system, application, and infrastructure configuration. Configuration management is frequently used in DevSecOps to ensure that systems are configured uniformly and deployed in a repeatable and reliable manner. This also refers to Infrastructure as Code and the use of tools such as Terraform, Ansible, Puppet, and Chef.

Container security:

The practice of securing containerised applications and environments. Container security is a key concern for DevSecOps, as containers are frequently used in modern software development and delivery pipelines to deploy and distribute applications via containers.

Continuous Delivery (CD):

A software development practice in which code changes are automatically created, tested, and deployed to production. (To ensure the integrity of engineers, CD changes are typically implemented in development and test systems, but changes in production may require manual approval).

CD differs from CI in that code changes must be ready for deployment at any time, whereas CI may require additional tests and validations before deployment.

Continuous Delivery also means that the software is always up to date and fully packaged, ready to go to production.

Continuous Deployment:

A software development practice in which code changes are automatically created, tested, and deployed to production without manual intervention (or first to a development system). Continuous delivery requires that code changes be thoroughly tested and validated before deployment to ensure they do not introduce new bugs or vulnerabilities. Depending on the application, compliance regulations may also affect CD.

Continuous Integration (CI):

Continuous Integration (CI) is a software development practice in which code changes are frequently integrated into a shared repository, and the integrated code is automatically built and tested. The main goal of CI is to detect and fix integration issues early in the development process, thereby reducing the risk of errors and other problems in the final product.

In CI, the software packaging pipeline is run with every code change, as you have already mentioned. This means that any change a developer makes to the codebase is automatically built, tested, and packaged into a deployable artifact. The result is immediate feedback on whether the changes have caused any issues and, if so, what those issues are.

Continuous Monitoring:

The practice of continuously monitoring systems and applications for signs of security breaches, vulnerabilities, or other issues. Continuous Monitoring helps organizations detect and respond to security threats and vulnerabilities in real time. It is a key component of DevSecOps.

DevOps:

A set of practices and tools aimed at improving collaboration between development and operations teams and accelerating the delivery of software updates. DevOps relies on automation and the use of tools such as Continuous Integration and Delivery to improve the speed and reliability of software updates.

DevSecOps:

A set of practices and tools aimed at integrating security practices into the software development and deployment process. It emphasizes collaboration between development, security, and operations teams. DevSecOps aims to build security into the software development lifecycle rather than treating it as an afterthought.

Dynamic Analysis:

A type of software inspection in which code is executed to identify errors, vulnerabilities, and other issues. Dynamic analysis is frequently used in DevSecOps to verify code behavior in real-world scenarios and to detect issues that may not be found by static analysis. In general, dynamic analysis involves analyzing and examining running applications. This allows you to review your applications and assess the risks or security vulnerabilities of third-party applications.

Incident Response:

Incident Response is a process by which companies detect, contain, and respond to security incidents or other unexpected events that could disrupt business operations. It involves a coordinated effort between various teams and stakeholders. The aim is to quickly identify, assess, and mitigate the impact of an incident.

One of the key tasks in incident response is resolving application outages, which can be caused by a variety of factors, such as network issues, software bugs, or security breaches. When an application goes down, the emergency team must act quickly to restore normal system operation and thereby prevent data loss or other negative impacts.

Infrastructure:

The hardware, software, and other resources that support the operation of a system or application. Infrastructure includes servers, storage, network devices, other hardware, as well as the software and tools used to manage and maintain these resources.

Infrastructure as Code (IaC):

A practice in which infrastructure configuration is expressed as code and managed and versioned using the same tools and processes as application code. With IaC, infrastructure can be more easily automated, tested, and integrated into the software development and deployment process. Furthermore, the configuration can remain as code, which saves a lot of manual work and is an important part of automation in Ops.

Penetration tests:

A type of security test in which an attacker simulates a real attack on a system or application to identify vulnerabilities and assess the security posture of the system. Penetration tests are frequently used in DevSecOps to identify and fix vulnerabilities before they can be exploited by real attackers.

Security as Code:

Security as Code is an approach to software development that integrates security practices into the software development lifecycle. It aims to make security a seamless and automated part of the development process. By embedding security checks and controls into the code itself, Security as Code is intended to reduce the risk of security vulnerabilities and facilitate the maintenance of a secure infrastructure over time.

In contrast to Infrastructure as Code (IaC), which focuses primarily on automating the creation and configuration of infrastructure resources, Security as Code goes beyond infrastructure automation and integrates security controls and policies into the code being developed.

Security automation:

The use of tools and processes to automate security tasks, such as vulnerability scans, incident response, and compliance reporting. Security automation is a key component of DevSecOps and helps companies improve the efficiency and effectiveness of their security practices.

Security tests:

Testing systems and applications for vulnerabilities, weaknesses, and other security issues. Security tests are an important part of DevSecOps and can include penetration tests, vulnerability scans, and code reviews.

Information security:

The practice of protecting systems, networks, and data from unauthorised access, use, disclosure, disruption, modification, or destruction. Within the scope of DevSecOps, security practices are integrated into the software development and deployment process to ensure that software updates are secure and do not introduce new vulnerabilities. Furthermore, information security involves isolating and securing the runtime environment of live applications.

Software delivery process:

The process of developing, testing, and deploying software updates. The software delivery process typically involves a series of steps, including requirements gathering, design, coding, testing, and deployment, and may involve collaboration between development, testing, and operations teams. The software deployment process aims to deliver high-quality software updates in a timely and efficient manner.

Static analysis:

A type of software testing in which code is analysed without executing it to detect errors, vulnerabilities, and other issues. Static analysis is frequently used in DevSecOps to identify and fix issues early in the software development process.

Test-Driven Development (TDD):

A software development practice in which tests for a piece of code are written before the code itself is written. TDD helps ensure that the code is developed in a testable manner and meets the requirements defined by the tests.

Threat modelling:

Identifying, analysing, and prioritising potential security threats to a system or application. Threat modelling is frequently used in DevSecOps to help organisations identify and fix potential vulnerabilities before they can be exploited by attackers.

Vulnerability scanning:

The practice of identifying vulnerabilities in systems and applications by examining them for known weaknesses. Vulnerability scanning is frequently used in DevSecOps to help organisations identify and prioritise vulnerabilities that need to be fixed.

Vulnerability:

A weakness or gap in a system or application that an attacker could exploit to gain unauthorised access, disrupt service, or steal or manipulate data. Within the scope of DevSecOps, vulnerabilities are identified and fixed as part of the software development and deployment process to prevent them from being exploited.

This DevSecOps glossar provides you with an initial overview of the various terms and definitions for everyday use. We continuously expand the glossary with additional and new terms.

BETTER CALL XALT

Ready to bring DevSecOps into your organization?

We help you build security into your software development process from the very start.

From the same category

More articles

Title graphic: 5 Steps to Building an Enterprise AI Harness on a dark blue background with network visualization.
DevOps

The Agent Harness: The Real Foundation of Enterprise AI

Why the agent harness – not the AI model or the generated code – determines the success of enterprise AI initiatives, and how to build one in five steps.

Illustration of zero trust and governance for agentic AI
DevOps

Governing Agentic AI Safely: Zero Trust and Compliance for AI Agents

AI agents are transforming the enterprise at speed – and the risk is growing just as fast. How the "in dubio pro securitate" principle, formal verification, and zero trust keep agentic AI safe and compliant.

Laptop displaying code on screen overlaid with a white icon of arrows and gear.
DevOps

Shift Left: Catching Bugs Earlier in Your Development Cycle

Bugs found late cost time, money, and trust. The shift-left approach moves testing and quality assurance as early as possible into the development cycle.