Knowledge base
Definitions for business owners, technology teams, and security practitioners, plus a direct explanation of where each concept fits in the Argus system.
Foundations
The most important distinction is simple: a public signal is not automatically a vulnerability, a vulnerability is not automatically exploitable in your environment, and technical severity is not the whole of business risk.
Every reachable or influenceable place where an attacker could try to enter, persist, move, extract data, or disrupt operations. It includes internet services, identities, APIs, software, cloud control planes, vendors, endpoints, and physical or operational systems.
Why it matters: you cannot reduce exposure until the business knows which systems, accounts, vendors, and connections create it.
Something the organization values or depends on, such as a domain, host, application, account, repository, cloud resource, identity system, mobile app, container image, or operational device.
Why it matters: every important system needs an owner, purpose, and clear relationship to the business process it supports.
A maintained record of assets, their owners, purpose, location, dependencies, exposure, and lifecycle. A list of IP addresses alone is not a complete inventory.
Why it matters: a reliable inventory prevents the same issue from being counted twice and reduces the chance that an unowned system is missed.
A condition that makes an asset reachable, discoverable, misconfigured, weakly controlled, or otherwise more available to a threat. Exposure may exist without a confirmed vulnerability.
Why it matters: exposure helps explain where an attacker could begin, but important decisions still require evidence about the actual weakness and business context.
A weakness in software, configuration, design, process, or control that can be used or triggered to violate a security objective.
Why it matters: a vulnerability becomes an actionable business issue when the affected system, practical impact, existing controls, and responsible owner are understood.
A structured security record describing an observed condition, the affected asset, supporting evidence, potential impact, recommended response, and lifecycle state.
Why it matters: a useful finding tells the team what is affected, why it matters, what to change, who owns it, and how closure will be verified.
Information that supports or refutes a claim: a response, configuration value, signed artifact identity, packet capture, source record, reproducible behavior, or verified state change.
Why it matters: evidence separates a confirmed condition from a scanner label, assumption, or sales claim and gives the team a way to verify the fix.
The effect of uncertainty on objectives. In cybersecurity, it is usually considered through threat likelihood, vulnerability or exposure, business impact, and the controls that change those factors.
Why it matters: business context explains why two technically similar weaknesses may require very different response priorities.
Prioritization
Severity, exploitation probability, known active use, reachability, and business importance should be combined deliberately, not collapsed into one unexplained number.
Common Vulnerabilities and Exposures provides a standard identifier for a publicly disclosed vulnerability. A CVE identifies an issue; it does not prove that a specific asset is affected or exploitable.
The Common Vulnerability Scoring System describes technical severity using defined metrics. It is useful context, but it is not a complete business-risk score or a remediation queue by itself.
The Known Exploited Vulnerabilities catalog lists CVEs for which CISA has evidence of exploitation in the wild. Presence in KEV is a strong prioritization input.
The Exploit Prediction Scoring System estimates the probability that exploitation activity for a CVE will be observed in the next 30 days. It measures threat probability, not business impact.
A sequence of conditions and relationships through which an attacker could progress from an initial position toward a security impact.
Multiple individually tolerable conditions that create serious risk together, such as public reachability, an exploitable flaw, excessive privilege, and access to sensitive data.
Identity and architecture
The process of establishing that an identity is who or what it claims to be. Passwords, passkeys, certificates, hardware keys, and device identity can all participate.
Why it matters: weak identity checks can turn one stolen password or session into access across email, cloud, financial, and customer systems.
Permission to perform a specific action. In security testing, authorization must identify the owner, exact scope, allowed techniques, timing, contacts, and stop conditions.
Why it matters: written authorization protects the organization and ensures testing stays inside systems and methods the owner approved.
Authentication requiring factors from different categories, such as something known, possessed, or inherent. Phishing-resistant methods reduce risks that ordinary one-time codes do not.
Why it matters: strong multi-factor authentication can stop a stolen password from becoming a business email compromise or administrative takeover.
Granting only the access required for a task, only for as long as needed. The principle applies to people, service accounts, applications, cloud roles, and automation.
Why it matters: limiting privilege reduces how far an attacker or mistake can reach after one account or system is compromised.
An architecture that does not grant implicit trust based only on network location. Access decisions use identity, device, resource, context, policy, and continuous evaluation.
Why it matters: the goal is to make each important access decision explicit instead of trusting a user or device simply because it is on the network.
Dividing systems and controlling communication between them to reduce reachable attack paths and contain failure. Network, identity, application, and tenant boundaries can all provide segmentation.
Why it matters: good separation can keep a problem in one office, account, workload, or vendor connection from becoming a business-wide incident.
Software and cloud
A Software Bill of Materials is a structured inventory of software components and related metadata. It supports dependency visibility, incident response, and vulnerability correlation, but does not prove that software is secure.
Examining code or a compiled artifact without executing it. It can reveal structure, identity, permissions, suspicious patterns, and policy issues; runtime behavior may still require separate validation.
A cryptographic mechanism for associating software with a signing identity and detecting changes after signing. A valid signature identifies and protects bytes; it does not guarantee secure behavior.
The security-relevant state of cloud identities, networks, resources, logging, encryption, and configuration compared with organizational requirements.
A packaged filesystem and metadata used to create container workloads. Image identity, components, configuration, runtime privileges, and deployment context all affect risk.
Operational technology and industrial control systems interact with physical processes. Safety, availability, vendor support, and fragile protocols often require more conservative assessment methods.
Response and governance
Changing a vulnerable condition or its cause, such as patching software, correcting configuration, reducing privilege, redesigning a trust boundary, or retiring an asset.
Why it matters: remediation needs an owner, target date, and verification step or a good recommendation can remain open indefinitely.
Reducing likelihood or impact when the underlying weakness cannot yet be removed. Blocking reachability or disabling a feature can mitigate risk without being the final fix.
Why it matters: a fast containment step can reduce immediate danger while the organization plans a more complete correction.
A documented decision to retain a known risk for a defined reason and period. Sound acceptance identifies an accountable owner, expiration, conditions, and review date.
Why it matters: acceptance is a leadership decision with a review date, not a way to make an uncomfortable finding disappear.
An alternate safeguard that meets the intent of a required control or materially reduces a specific risk when the preferred control is unavailable.
Why it matters: an alternate control can make a difficult risk manageable, but the team should still understand what remains.
A focused reassessment after change to determine whether the original condition is still present and whether the change introduced a new issue.
Why it matters: retesting replaces an assumption that the fix worked with a documented before-and-after result.
Evidence and analysis about threats, adversary behavior, exploitation, infrastructure, and campaigns used to improve decisions. It has a source, collection time, confidence, and shelf life.
Why it matters: current exploitation evidence can change priority, but it still must be connected to the systems and controls in your environment.