Skip to content


Build System

A system that takes the source code and builds the firmware image to be flashed on the device.


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.


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).


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.


When your firmware component uses another open source or proprietary library, this other component becomes a dependency to your own software.

  • A direct dependency is a library you include in your own project.
  • An indirect dependency (also known as a deep, chained, or transitive dependency), is a library that is used by one of your direct dependencies.

Dependency tree

(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 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 distributed version-control system for tracking changes in source code during software development.


Third-party products, applications and platforms that BugProve works with, for example SCM systems such as GitHub.


A storage area that contains all elements necessary for building the embedded system or elements necessary for provisioning these.


Static Application Security Testing. A method to secure software by reviewing the source code of your proprietary software, and identifying sources of vulnerabilities.


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 severity level is applied to a vulnerability. BugProve uses CVSS v2 and v3 as scoring systems for all findings


A security vulnerability, identified by BugProve.