The parent image used to construct a container image, usually defined in the FROM directive in a Dockerfile. Base images themselves can be constructed from other base images.
A system that takes the source code and builds the deployable application (such as a container).
Continuous integration (CI), continuous delivery (CD) and continuous deployment (CD) together comprise an SDLC model, guiding developers to automate development and delivery of small, frequent changes. This ensures all team members have access to the latest code base and can ensure the compatibility of committed code during development.
Implementing security throughout the CI/CD pipeline, automating security embedding in microservices and maximizing repetition to reduce the introduction of vulnerabilities. Snyk provides a comprehensive CNAS platform. See our article about Cloud native security guide for building secure applications.
Containers allow you to package applications and their dependencies together, to be deployed as a single runnable unit. A container is an abstraction provided by the operating system kernel, that allows a process to be isolated from other processes running on the system. Also see Snyk Container.
For users, an application which takes a container image and turns it into a running container. Container engines typically interface with container registries, and run containers. Examples of container engines include Docker, CRI-O or LXC.
One or more files which, when instantiated by a container engine or runtime, provide a running container. Images are the packaging and distribution format for containers.
A server which provides a mechanism to store and retrieve container images.
Common Vulnerabilities and Exposures. A widely-used identifier for a well-known vulnerability.
Common Vulnerability Scoring System. An industry standard to assess the severity of vulnerabilities, using a score of 0 (lowest) to 10 (highest). Snyk uses CVSS.
Common Weakness Enumeration, an online glossary that categorizes software and hardware weaknesses into different types. For example: CWE-20: Input Validation.
Dynamic Application Security Testing. An application that you can point at a site or service; it then typically profiles the site or service, then examines the output and behaviour to uncover security vulnerabilities. Also see SAST.
When your application uses another package, this other package becomes a dependency to your own software.
- A direct dependency is a package you include in your own project.
- An indirect dependency (also known as a deep, chained, or transitive dependency), is a package that is used by one of your direct dependencies.
(Also known as Dependency path) A hierarchical graph showing the dependencies of a software application. This includes both direct and indirect dependencies, and so may be many levels deep.
A set of cultural philosophies, practices, and tools that combines software development and IT operations, to shorten the systems development life cycle.
The integration of security into emerging agile IT and DevOps development as seamlessly and as transparently as possible.
A text file format used to build container images using Docker. The Dockerfile contains all the commands needed to construct the final image, including specifying the parent base image.
A demonstration of how a vulnerability can be taken advantage of. When an exploit is widely published, it is commonly referred to as an exploit in the wild.
A measure of how practical an exploit for a vulnerability is, based on whether the exploit is in the wild, and how "helpful" the exploit is to attackers. See Evaluating and prioritizing vulnerabilities.
A pull request with an automatic fix for vulnerabilities found that Snyk can offer the user.
A distributed version-control system for tracking changes in source code during software development.
Integrated Development Environment. An application giving facilities for software development, typically with a source code editor, build automation tools and a debugger.
The stored instance of a container that holds a set of software needed to run an application.
Container images typically consist of several different filesystem layers, which are combined together at runtime into a single filesystem.
Third-party products, applications and platforms that Snyk works with, for example SCM systems such as GitHub.
A license problem, vulnerability, or misconfiguration identified and listed by Snyk.
A specific type of a package.
A file containing metadata about other files in a package.
A run of the snyk monitor command that tests the project and uploads results to Snyk.
Open Container Initiative. An independent body set up to facilitate collaboration around standards for containers, to ensure they are interoperable between vendor solutions.
An organization in Snyk is a way to collect and organize your projects. Members of organizations can then access these projects.
A group of files and additional metadata about those files, used by package managers.
A set of tools that automates and manages packages of bundled files, and are usually specific to a language. For example, npm.
A software package hosting service that allows customers to host packages and code in one place.
A fix type: define and "pin" a specific version of an indirect dependency, to avoid a direct dependency pulling in a vulnerable version.
Pull Request. Allows a user to exchange changes made to source code and collaborate with others on the same branch.
Snyk scores issues (vulnerabilities and licenses), to help prioritze treatment of each one. Scores are based on multiple factors including as the CVSS score, and range from 0 (low) to 1000 (high). See Snyk Priority Score.
A storage area that contains all elements necessary for the distribution of an application.
A cloud infrastructure entity such as an AWS S3 bucket, Identity & Access Management (IAM) role, or Virtual Private Cloud (VPC) flow log.
A security policy that checks cloud infrastructure and infrastructure as code (IaC) for misconfigurations that can lead to security problems.
Static Analysis Results Interchange Format. A standard, JSON-based format for the output of static analysis tools.
Software Bill Of Materials. A list of components in a piece of software.
Software Composition Analysis. Technology used to identify open-source and third-party components in use in an application, including their known security vulnerabilities, and typically adversarial license restrictions.
Source Code Management. Also known as a code repo / repository / version control system. The method used by developers to store their source code, and track changes to code. SCM helps resolve conflicts when merging updates from multiple contributors. GitHub is an example of a common SCM system.
Software Development Life Cycle. A process followed by a development team, describing how to develop and, maintain software.
A set of criteria for evaluating open source vulnerabilities. Security policies enable you to set custom rules to automatically prioritize or de-prioritize specific vulnerabilities. The Snyk Default Security Policy is enabled by default, or you can create your own security policy. See Security policies.
A method to provide pay-as-you-use backend computing services, allowing applications to be constructed entirely from functions provided by the supplier. Examples of serverless providers include AWS Lambda and Azure Functions.
An individual report within a project’s test history. Includes a tree of dependancies, and a list of vulnerabilities that was accurate at the time the test was conducted.
A platform providing Cloud Native Application Security (CNAS) solutions, allowing developers to own and build security for the whole application, from code and open source to containers and cloud infrastructure. See What is Snyk?.
Snyk is also the company providing the Snyk platform.
A free web application which allows you to compare software packages across open source ecosystems. It provides insights into the overall health of a particular package by combining community and security data into a single unified view. See Snyk Advisor.
Snyk Apps are the modern and preferred way to build integrations with Snyk, exposing fine-grained scopes for accessing resources over the Snyk APIs, powered by OAuth 2.0 for a developer-friendly experience. For more information see Snyk Apps.
A client/server system that serves as an agent / proxy, allowing Snyk to scan private customer environments (Jira, code repositories or container registries). It relays messages and allows users to filter which messages are allowed through; for example, allowing users to expose only some Github APIs to Snyk. See Snyk Broker documentation.
A library used by the Snyk CLI to scan a certain language/build system.
A component powering Snyk’s cloud native application security platform. Incorporates Snyk Intel Vulnerability DB: Snyk’s database of vulnerabilities, providing detailed information and fix advice for known vulnerabilities. See Vulnerability DB.
Software Package Data Exchange. A file format used to document information on the software licenses under which a piece of computer software is distributed.
Representation of an external resource Snyk has scanned through an integration, the CLI, UI or API. Targets may represent a SCM repository, a Kubernetes workload, or other scannable resources external to Snyk. All projects that Snyk create are associated to a parent target. One target may relate to many projects. The structure of the target depends on the origin. See Introduction to projects.
A fix type: a problem can be fixed by upgrading a version of a package, or by applying a patch.
A way for an app to provide other applications with real-time information. Snyk uses webhooks to check changes in code.