CySA+ Control Types, Risk Management and Application Security (SAST, DAST, SAMM, SBOM)

A control's type says what the control is made of: administrative controls are rules and people processes, technical controls are enforced by hardware or software, and physical controls act on the physical world. CompTIA lists these three types for CS0-004, and every control fits one of them.

"Operational" is not another name for physical. Older frameworks (NIST SP 800-53 Rev. 3 and earlier) and earlier CySA+ versions grouped controls as management, operational and technical, where operational meant controls run by people day to day, such as awareness training, incident response and configuration management. Those people-run controls map mostly to administrative under CS0-004, and CompTIA Security+ lists physical as a category of its own beside managerial, operational and technical.

Classify by how the control is enforced, not by the document that asked for it. A standard requiring screens to lock after a period of inactivity is administrative; the endpoint configuration that locks them automatically is technical, because software enforces it. A person reading log reports is administrative even though the logs come from a computer.

Type is only half of a control's description. The other half is its function (next section), and the two are independent: a security guard at a gate is physical and preventative, restoring a database from backup is technical and corrective, and a manager reviewing access reports is administrative and detective. When a question asks for one cell of a type-by-function matrix, answer both questions separately for each candidate control, and reject a control that matches only one of them.

A control's function says what it does in relation to an incident: preventative controls stop it happening, detective controls find and record it, responsive controls act on it while it is in progress, and corrective controls restore and fix things afterwards.

Classify by what the control does today

The same product can perform different functions depending on configuration and placement. A DLP tool in monitor-only mode that logs and reports but still delivers the message is detective; switched to block mode it becomes preventative. Placement matters as much as mode. A sensor fed by a SPAN (mirror) port or a passive tap receives only a copy of the traffic, so it can observe and alert but cannot stop anything, whatever its product name or rule actions say: it is detective. Prevention needs an inline position, where traffic must pass through the device, plus a blocking mode. Improving what a detective control detects, or where its alerts go, makes it a better detective control; it does not make it preventative.

Responsive vs corrective

The two are easy to confuse because both happen after something has gone wrong. Responsive controls act on an incident still in progress, to limit its spread: isolating a host, blocking an account, paging the on-call analyst. Corrective controls act once the incident is contained, to return to a known-good state and remove the cause: restoring from immutable backups, rebuilding, patching. Ask: "Is this stopping the damage now, or repairing it afterwards?"

Inherent risk is the level of risk before any controls are applied; residual risk is the level that remains after controls; and risk appetite is the amount and type of risk the organization's leadership (ultimately the board) is willing to take on in pursuit of its objectives. Residual risk is what you compare with appetite.

Many organizations score risk as likelihood × impact on simple ordinal scales (for example 1–5 each). A risk register entry typically records an inherent rating, the controls in place, and a residual rating. Work the arithmetic exactly. If a phishing risk scores likelihood 3 × impact 4 = 12 before controls, and awareness training lowers likelihood to 2 while impact stays at 4, the residual score is 8. Judge that residual score against the threshold the policy sets, not by how much it fell. If it is still above, the policy's options apply: further treatment, or acceptance by someone with the authority to accept that level.

Using appetite to make decisions

• Appetite is set per category. A company can have a low appetite for customer-data confidentiality risk and a moderate appetite for schedule risk. When a decision trades one category against another, the lower-appetite category wins. A company with a low appetite for regulatory penalties and a moderate appetite for cost overruns should pay more for the compliant option.
• Acceptance needs matching authority. A risk beyond stated appetite can be accepted only by the body that set the appetite or someone it has delegated that level of authority to.
• Do not over-treat in-appetite risk. Treatment budget goes first to risks above appetite. A risk already within appetite is normally retained, especially when further controls would cost more than the loss they prevent.
• Appetite vs tolerance. Appetite is the broad level of risk the organization wants to pursue; tolerance is the acceptable variation around it for a specific objective or metric. Neither is a measured risk level for a particular asset.

Once a risk is assessed, the organization treats it in one of four ways: mitigate it with controls, transfer its financial impact to another party, avoid it by not doing the risky activity, or accept it as it is.

Avoid vs mitigate

The test is whether the risky activity continues. Shutting down a risky system or process is avoidance: the exposure no longer exists. Hardening it and keeping it running is mitigation. Redesigning a plan so it reaches the same goal without the risky element is also avoidance: an age check that records only "over 18: yes" instead of a full date of birth never holds the sensitive data. Protecting sensitive data you still collect only mitigates the risk, and having someone else process it on your behalf does not remove your own obligations for it.

Mitigation can target likelihood or impact

Controls that make the event less likely include MFA, patching, phishing training and network restrictions. Controls that reduce the damage if it happens anyway include tokenizing stored card numbers (a breach exposes tokens that are useless to the thief), segmentation that limits how far an intruder can spread, and a tested disaster recovery plan. A useful check: does the control still help after the event has occurred? If yes, it reduces impact.

Accepting and transferring properly

A valid risk acceptance is a formal decision by the accountable risk owner (normally the business owner of the asset or process, not the analyst who found the issue), recorded with the rationale and a review date in the risk register. A valid transfer shifts some of the financial impact to another party while the organization keeps accountability.

Making an acceptance valid

• Owned: someone with authority over the asset and budget signs it off. The person who found the issue cannot accept it on the owner's behalf.
• Documented: the risk register records what is accepted, why (for example, residual risk within appetite, or the only fix costs more than the expected loss), and any conditions.
• Reviewed: acceptance expires. It is reviewed on its date or when its assumptions change, whichever comes first. A change in exploitability, such as a working exploit appearing or the flaw being listed in CISA's Known Exploited Vulnerabilities catalogue, is a typical trigger to reassess early with the risk owner.
• Not hidden: making a finding disappear from reports is not acceptance; it only removes visibility.

What transfer does and does not move

Insurance pays for some losses; outsourcing moves the operation to a provider; an indemnity clause makes a contractor reimburse losses caused by its own failures. All three move financial consequences. None moves accountability: regulators, customers and the press still hold the organization responsible, and reputational damage is not reimbursed. Outsourcing a regulated function to a certified provider narrows what the company handles, but it does not end the company's own compliance obligations. It is normal to transfer part of a risk and then formally accept what remains.

A policy states management's intent and assigns responsibility; a standard sets mandatory, measurable requirements that implement the policy; a procedure gives the mandatory step-by-step instructions; and a guideline offers recommended but optional advice. Governance is the structure of accountability, decision rights and oversight that makes these documents mean something.

Two signals separate a standard from a policy: a standard is specific and measurable (a severity threshold, a number of days, a scope), and it applies the policy rather than stating intent. Two signals mark a guideline: words like "recommend" or "suggest", and nobody is measured against it.

Governance fixes ownership gaps

When findings are reported reliably but stay open because no one is required to fix them, the root cause is missing accountability, not the detection process. The fix is governance: an executive-approved policy that assigns remediation responsibility to system owners, backed by standards with timeframes. Technical or advisory changes cannot stand in for assigned accountability.

A remediation service-level objective (SLO) is an internal target for how quickly findings of each severity must be fixed, measured from a defined start point (usually the detection date). SLOs turn the vulnerability management standard into something you can measure, report and escalate.

A typical standard sets a separate timeframe per severity, often shorter for internet-facing or actively exploited findings. To find breaches, compare each open finding's age (today minus its detection date) with its own severity's target. The oldest finding or the most severe one is not necessarily the one in breach: with targets of 14 days for high and 60 days for medium, a medium finding 50 days old is within target, while a high finding 20 days old has breached. Count calendar days carefully across month boundaries.

SLO vs SLA

The two must line up. If a supplier's contracted timeframe is longer than the internal objective it supports, the supplier can meet its SLA every time while the organization still misses its SLO. Contract remedies apply only to breaches of the contract, and lowering your own objective to fit a supplier lowers security. Supplier SLAs should be aligned with the internal SLOs they serve; individual exceptions suit isolated cases, not a systematic mismatch (exceptions and compensating controls are covered in the vulnerability prioritization and mitigation lesson).

Static application security testing (SAST) analyses source code, bytecode or binaries without running them, and reports flaws at the file and line where they occur. Dynamic application security testing (DAST) attacks a running application from the outside, the way a user or attacker would, without needing the source code.

The two are complementary, which is why mature pipelines run both. When the constraint is "no source code" (for example, a purchased application delivered only as a build), SAST is not available and DAST of the running instance is the fit. When feedback is needed at the moment code changes, before anything runs, SAST is the fit. Interactive application security testing (IAST) instruments the running application to combine both views, but it still needs a running instance.

Authenticated DAST

A DAST scan is only as good as its coverage. Check the crawl or request log: if the scanner never got past the public pages, everything behind sign-in went untested, and a near-empty report means low coverage, not a clean application. Authenticated scanning (credentials for a test account, a scripted login and session handling) lets the crawler reach those functions. A quiet report is never evidence of security until you have checked what was reached.

The OWASP Software Assurance Maturity Model (SAMM) is an open, vendor-neutral framework for measuring how mature an organization's secure software development practices are and for planning improvements. It is prescriptive: it tells you what good looks like and what to do next.

SAMM v2 is organized into five business functions, each with three security practices. Each practice is scored against maturity levels (1 to 3), so an organization can assess its current state, set target levels and build a phased roadmap.

Threat modelling, identifying and ranking threats while the architecture is being drawn up, is the Threat Assessment practice, which sits under Design. Place a practice by what it is, not by the phase in which its absence is noticed.

Related resources that are not SAMM

The quick distinction: SAMM is about your programme's maturity and next steps, BSIMM is about what others are observed doing, and ASVS is about a single application's requirements. CVSS, by contrast, scores individual vulnerabilities and has nothing to do with programme maturity.

Third-party risk is the risk that a supplier, service provider or the software and hardware they deliver harms your organization; supply chain risk is the part of it that enters through the products and updates you receive. You manage it with assurance before onboarding, contract terms that keep your rights during the relationship, and technical controls that assume trusted suppliers can be compromised.

Assurance evidence

Type II is the stronger evidence because it tests operation, not just design. A SOC report also lets a provider give independent assurance to many customers without hosting each customer's auditors.

Contract terms

• Right to audit: lets you (or your appointed auditor) examine the supplier's controls yourself, on reasonable notice, during the contract.
• Indemnification: decides who pays for losses caused by a party's failures (a form of transfer).
• Service-level agreement: how well and how fast the service must perform.
• Non-disclosure agreement: keeps shared information confidential.

Compromised updates

If attackers breach a vendor's build system, the malicious update can be signed with the vendor's genuine key (as in the 2020 SolarWinds Orion compromise). A valid signature proves who shipped the code, not that it is safe. Treat trusted third-party software as if it could turn hostile: give it least-privilege network access, limit its egress to the destinations it genuinely needs, and monitor for unexpected outbound connections, so a backdoor that does get in has a hard time reaching its operators.

Software composition analysis (SCA) inventories the open-source and third-party components an application uses and flags those with known vulnerabilities or licences that break company rules. A software bill of materials (SBOM) is the machine-readable list of those components, with versions, that lets anyone answer "are we affected?" by searching instead of asking.

SCA: other people's code

SAST examines the code your team writes; SCA examines the packages you pull in. A modern service may declare a few dozen direct dependencies and resolve hundreds of transitive ones (dependencies of dependencies). The manifest (for example package.json) shows what you chose; the lockfile (for example package-lock.json) shows everything the package manager resolved and what actually ships. A vulnerable library absent from the manifest but present in the lockfile and the build is almost always a transitive dependency, and it is a real finding. SCA belongs in the build pipeline so every build is checked for both CVEs and licence conflicts.

Prioritising SCA findings

SCA tools often report hundreds of findings, and most sit in transitive packages. Severity scores alone do not separate the findings that matter, and transitive findings are still real. Focus first on findings where reachability analysis shows the application's code can actually call the vulnerable function, then on exploitability (known exploitation, exploit availability). Present is not the same as reachable.

SBOM formats

The two established SBOM standards are SPDX (Linux Foundation; published as ISO/IEC 5962:2021) and CycloneDX (OWASP; standardized as ECMA-424). Other security data formats carry scan results, threat intelligence or assessment checks; they are not component inventories. Requiring an SBOM from suppliers with every release turns "are we affected by this new library flaw?" into a search across your own inventory.

VEX: "present, but not affected"

An SBOM lists what is inside; it does not say whether a known CVE is exploitable in the product. A Vulnerability Exploitability eXchange (VEX) document does. It records a product's status for a specific vulnerability as not affected (with a justification, such as the vulnerable code not being present in the build), affected, fixed or under investigation. VEX can be carried in CycloneDX, CSAF or OpenVEX. The SBOM should stay an accurate inventory; VEX is how a supplier says that a listed component's CVE does not apply.