Instructions
Read the text in full, paying special attention to the concrete examples and bullet list recap. While reading, write down one example from your own professional environment for each of the four key terms. After finishing, re-read your examples and verify they respect the definitions provided. Keep your notes; you will use them in the upcoming multiple-choice quiz.
Contenu
Cybersecurity and DevSecOps are both fields that rely on precise, shared vocabulary. Before you can prioritize tests, perform penetration testing, or automate security controls in a delivery pipeline, you must be able to describe what you are protecting, what might go wrong, how it might go wrong, and how bad the consequences could be. The four foundational words that organise this reasoning are security, threat, vulnerability, and risk. The following narrative explains each term clearly, contrasts it with the other terms, and illustrates it with concrete, practical examples that beginners can immediately reuse when analysing real systems.
Security means the condition in which an asset is protected against unauthorised loss of confidentiality, loss of integrity, loss of availability, or loss of accountability. Confidentiality means information is not disclosed to unauthorised entities; integrity means information is not altered or destroyed in an unauthorised manner; availability means information or a service can be used when required; accountability means actions can be traced to an individual or process. Security, therefore, is not a single switch but a multi-dimensional state. For example, if a source code repository can be read by anyone on the internet, confidentiality is broken even if integrity and availability remain intact. In that situation the repository is not secure.
The term information security traditionally covers protection of data in any form, while the term cyber security emphasises the digital environment (networks, computers, connected devices). In DevSecOps we embed the same security objectives directly inside development and operations workflows. Whatever the context, the measurable goal remains identical: preserve confidentiality, integrity, availability, and accountability of assets.
An asset is anything that has value to an organisation or individual and therefore must be protected. Assets include customer databases, proprietary source code, cryptographic keys, billing systems, container orchestration clusters, build servers, even brand reputation. When we talk about security we implicitly talk about protecting assets.
A threat is a potential cause of an unwanted incident that may result in harm to a system or organisation. A threat is never the weakness itself; it is the possibility that somebody or something will exploit a weakness. Threats always involve a threat actor (the entity that could cause harm), a target asset, and a motive (why the actor wants to cause harm). Threat actors may be external criminals looking for easy money, insiders looking for revenge, competitors seeking industrial espionage, hacktivists aiming to deface a site, or even accidental factors such as a misconfigured script that deletes log files. A single event can manifest several threats simultaneously.
Explicit examples make the word threat concrete:
• A criminal on a public Wi-Fi network might attempt to intercept unencrypted credentials sent by a mobile application. The threat is interception of credentials; the actor is the criminal; the asset is the credentials; the motive is profit through account takeover.
• A disgruntled system administrator may try to delete backups before quitting. The threat is deliberate data destruction; the actor is an insider with privileged access; the asset is backup data; the motive is sabotage.
• A power outage is a non-human threat that could stop a self-hosted continuous integration server, affecting availability. The asset is the integration service; the actor is nature; the motive is irrelevant; the threat is service disruption.
Notice how no weakness is mentioned in the threat description. A threat can loom over a perfectly hardened system; it only becomes active when a vulnerability provides an opening.
A vulnerability is a weakness that can be exploited by a threat to violate the security of an asset. Vulnerabilities may reside in software (buffer overflow in a C library), hardware (side-channel timing flaw in a processor), configuration (open S3 storage bucket), design (lack of rate limiting on an authentication endpoint), or even the human layer (lack of security awareness training). A vulnerability does not automatically imply damage: if no threat actor knows or cares about it, the weakness may lie dormant for years. Nonetheless, once a vulnerability is known, the clock starts ticking because someone might exploit it.
Concrete vulnerability examples help fix the concept:
• An outdated WordPress plugin containing an SQL injection flaw is a software vulnerability. If a criminal finds it, database contents can be dumped.
• A continuous delivery pipeline that stores private keys in plaintext on the build server is a configuration vulnerability. Anyone who gains access to that machine can steal the keys.
• Re-using the same password for personal and corporate email is a human vulnerability. A phishing campaign can harvest the password from a leisure site breach and reuse it on the professional account.
Note the essential difference between threat and vulnerability: the threat is the possible attacker or circumstance, whereas the vulnerability is the door that attacker might use. You can have a threat without a vulnerability (for example, a burglar eyeing a house with reinforced doors and no windows), and you can have a vulnerability without an immediate threat (for example, a zero-day flaw that nobody has discovered yet), but damage happens only when both combine.
Risk is the combination of the likelihood that a given threat will exploit a given vulnerability and the impact that exploitation would cause. Risk is therefore a statement about future uncertainty plus potential severity. The formal formula often used is Risk = Likelihood × Impact. While multiplying numbers is a simplification, the expression reminds us that both ingredients matter. A critical vulnerability with low exploit probability may present the same risk level as a moderate vulnerability that is almost certain to be exploited.
To evaluate risk you proceed in four steps: identify the asset, identify relevant threats, identify existing vulnerabilities, then estimate how likely exploitation is and how bad the result would be. This structured reasoning is called risk assessment.
Example risk assessment scenario:
1. Asset: Customer credit card database stored in a relational database management system.
2. Threat: External attacker seeking profit from stolen cards.
3. Vulnerability: SQL injection in the public product search function.
4. Likelihood: High, because injection is easy to automate and the URL is public.
5. Impact: Critical, because disclosure of card data triggers regulatory fines under the Payment Card Industry Data Security Standard and loss of customer trust.
6. Risk: High. Immediate remediation is mandatory (for example, deploy prepared statements and input validation, add Web Application Firewall rule, run non-regression tests).
Contrast with another scenario:
1. Asset: Marketing image files stored on a test server.
2. Threat: Same external attacker.
3. Vulnerability: Directory listing enabled.
4. Likelihood: High (public URL).
5. Impact: Low (images are public anyway).
6. Risk: Low. Remediation can be postponed until higher priorities are addressed.
The examples show why risk is not identical to vulnerability. Both scenarios have a vulnerability that is easy to exploit, but the first scenario carries a higher risk because the impact is far greater. In DevSecOps, such prioritisation drives backlog grooming and sprint planning.
Because risk combines probability and impact, defenders have two broad strategies. They can reduce likelihood (for example by patching software, closing ports, adding encryption, segmenting networks) or reduce impact (for example by backing up data, implementing redundant servers, purchasing cyber insurance). A mature security program applies both levers according to budget and... (download to read the rest 👇)
Security means the condition in which an asset is protected against unauthorised loss of confidentiality, loss of integrity, loss of availability, or loss of accountability. Confidentiality means information is not disclosed to unauthorised entities; integrity means information is not altered or destroyed in an unauthorised manner; availability means information or a service can be used when required; accountability means actions can be traced to an individual or process. Security, therefore, is not a single switch but a multi-dimensional state. For example, if a source code repository can be read by anyone on the internet, confidentiality is broken even if integrity and availability remain intact. In that situation the repository is not secure.
The term information security traditionally covers protection of data in any form, while the term cyber security emphasises the digital environment (networks, computers, connected devices). In DevSecOps we embed the same security objectives directly inside development and operations workflows. Whatever the context, the measurable goal remains identical: preserve confidentiality, integrity, availability, and accountability of assets.
An asset is anything that has value to an organisation or individual and therefore must be protected. Assets include customer databases, proprietary source code, cryptographic keys, billing systems, container orchestration clusters, build servers, even brand reputation. When we talk about security we implicitly talk about protecting assets.
A threat is a potential cause of an unwanted incident that may result in harm to a system or organisation. A threat is never the weakness itself; it is the possibility that somebody or something will exploit a weakness. Threats always involve a threat actor (the entity that could cause harm), a target asset, and a motive (why the actor wants to cause harm). Threat actors may be external criminals looking for easy money, insiders looking for revenge, competitors seeking industrial espionage, hacktivists aiming to deface a site, or even accidental factors such as a misconfigured script that deletes log files. A single event can manifest several threats simultaneously.
Explicit examples make the word threat concrete:
• A criminal on a public Wi-Fi network might attempt to intercept unencrypted credentials sent by a mobile application. The threat is interception of credentials; the actor is the criminal; the asset is the credentials; the motive is profit through account takeover.
• A disgruntled system administrator may try to delete backups before quitting. The threat is deliberate data destruction; the actor is an insider with privileged access; the asset is backup data; the motive is sabotage.
• A power outage is a non-human threat that could stop a self-hosted continuous integration server, affecting availability. The asset is the integration service; the actor is nature; the motive is irrelevant; the threat is service disruption.
Notice how no weakness is mentioned in the threat description. A threat can loom over a perfectly hardened system; it only becomes active when a vulnerability provides an opening.
A vulnerability is a weakness that can be exploited by a threat to violate the security of an asset. Vulnerabilities may reside in software (buffer overflow in a C library), hardware (side-channel timing flaw in a processor), configuration (open S3 storage bucket), design (lack of rate limiting on an authentication endpoint), or even the human layer (lack of security awareness training). A vulnerability does not automatically imply damage: if no threat actor knows or cares about it, the weakness may lie dormant for years. Nonetheless, once a vulnerability is known, the clock starts ticking because someone might exploit it.
Concrete vulnerability examples help fix the concept:
• An outdated WordPress plugin containing an SQL injection flaw is a software vulnerability. If a criminal finds it, database contents can be dumped.
• A continuous delivery pipeline that stores private keys in plaintext on the build server is a configuration vulnerability. Anyone who gains access to that machine can steal the keys.
• Re-using the same password for personal and corporate email is a human vulnerability. A phishing campaign can harvest the password from a leisure site breach and reuse it on the professional account.
Note the essential difference between threat and vulnerability: the threat is the possible attacker or circumstance, whereas the vulnerability is the door that attacker might use. You can have a threat without a vulnerability (for example, a burglar eyeing a house with reinforced doors and no windows), and you can have a vulnerability without an immediate threat (for example, a zero-day flaw that nobody has discovered yet), but damage happens only when both combine.
Risk is the combination of the likelihood that a given threat will exploit a given vulnerability and the impact that exploitation would cause. Risk is therefore a statement about future uncertainty plus potential severity. The formal formula often used is Risk = Likelihood × Impact. While multiplying numbers is a simplification, the expression reminds us that both ingredients matter. A critical vulnerability with low exploit probability may present the same risk level as a moderate vulnerability that is almost certain to be exploited.
To evaluate risk you proceed in four steps: identify the asset, identify relevant threats, identify existing vulnerabilities, then estimate how likely exploitation is and how bad the result would be. This structured reasoning is called risk assessment.
Example risk assessment scenario:
1. Asset: Customer credit card database stored in a relational database management system.
2. Threat: External attacker seeking profit from stolen cards.
3. Vulnerability: SQL injection in the public product search function.
4. Likelihood: High, because injection is easy to automate and the URL is public.
5. Impact: Critical, because disclosure of card data triggers regulatory fines under the Payment Card Industry Data Security Standard and loss of customer trust.
6. Risk: High. Immediate remediation is mandatory (for example, deploy prepared statements and input validation, add Web Application Firewall rule, run non-regression tests).
Contrast with another scenario:
1. Asset: Marketing image files stored on a test server.
2. Threat: Same external attacker.
3. Vulnerability: Directory listing enabled.
4. Likelihood: High (public URL).
5. Impact: Low (images are public anyway).
6. Risk: Low. Remediation can be postponed until higher priorities are addressed.
The examples show why risk is not identical to vulnerability. Both scenarios have a vulnerability that is easy to exploit, but the first scenario carries a higher risk because the impact is far greater. In DevSecOps, such prioritisation drives backlog grooming and sprint planning.
Because risk combines probability and impact, defenders have two broad strategies. They can reduce likelihood (for example by patching software, closing ports, adding encryption, segmenting networks) or reduce impact (for example by backing up data, implementing redundant servers, purchasing cyber insurance). A mature security program applies both levers according to budget and... (download to read the rest 👇)