Most of my cybersecurity career has focused on Vulnerability Risk Management. This is the continuous process of auditing a computer network for security issues, evaluating the risk to the organization, prioritizing what needs to be fixed first ("Should a vendor patch be applied? Do we need our programmers to create and push a fix to their own code? Should our network engineers make a configuration change?"), coordinating with various teams to apply the fixes, and documenting that the issues were successfully addressed.

At home, I impress upon my mother to always keep her devices updated, including her smartphone, her laptop, and the apps installed on both. Despite the occasional complaint about how the look and feel of something changed, she has embraced staying on the latest updates.

In this post, we will explore what a bug is, how that bug can become a security vulnerability, how the security community reports, publishes, and communicates information about vulnerabilities, and lastly, why and how to keep your devices and apps updated.

The First Computer Bug

The term "bug" in the context of issues arising in machinery and circuitry is credited to Thomas Edison in the 1870s. The first documented bug in a computer system occurred in 1947. Electrical engineers at Harvard University, whose team included the famous computer scientist Grace Hopper, were developing the Harvard Mark II computer on behalf of the United States Navy. The Mark II, also known as the Aiken Relay Calculator after physicist and computer pioneer Howard Aiken who was also a leading member of the Harvard team, was the size of a house and weighed over 25 tons. The Mark II used electromagnetic relays, could calculate floating-point (i.e., decimal numbers, an improvement over earlier machines), and performed complex mathematical functions such as logarithms and square roots.

During the team's work, a moth was found stuck in one of the relays, a literal computer "bug" that caused the computer to malfunction. Removing the bug humorously reinforced the term "debug" that's still used in programming and software engineering today. The logbook from this incident, including the preserved moth, is part of the Smithsonian's collection at the National Museum of American History Behring Center.

Software bugs as we know them today stem from errors in software development, whether by poor design or by the honest mistake of a stressed programmer writing code on a tight schedule. Bugs are a seemingly never-ending issue that can lead to unexpected behavior from a computer program, and given the enormity and complexity of software codebases today, this trend is unlikely to change. Artificial Intelligence (AI) can help in some respects through automated code review and AI-generated code, but these advancements can lead to other issues in software as well.

When a Bug Becomes a Security Concern

When a bug affects a computer such that it can have a measurable effect on the Confidentiality, Integrity, or Availability of the system and its data (what cybersecurity refers to as the CIA triad), the bug becomes a security vulnerability, a weakness in software that can be targeted and potentially exploited by a malicious actor leading to an impact. The U.S. National Institute of Standards and Technology (NIST) generally defines a vulnerability in a few different Special Publications (SP) as:

"Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited by a threat source."

This definition stems from another publication from The Committee on National Security Systems (CNSS), CNSSI No. 4009: "Committee on National Security Systems (CNSS) Glossary" which can be found in the U.S. National Archives. This document attempts to provide a common nomenclature and authoritative definitions usable across different federal government entities, such as NIST and the U.S. Department of Defense (DoD), and to resolve any conflicts or differences between the terms used by different entities. CNSSI No. 4009 defines vulnerability as:

"A known weakness in a system, system security procedures, internal controls, or implementation by which an actor or event may intentionally exploit or accidentally trigger the weakness to access, modify, or disrupt normal operations of a system-resulting in a security incident or a violation of the system's security policy."

Additionally, CNSSI No. 4009 provides the U.S. Department of Homeland Security's (DHS) nomenclature (i.e., lexicon) of a vulnerability as:

"Characteristic of design, location, security posture, operation, or any combination thereof, that renders an asset, system, network, or entity susceptible to disruption, destruction, or exploitation. See weakness."

DHS's term for weakness is:

"An attribute or characteristic that may, under known or unknown conditions, render an entity, asset, system, network, or geographic area open to exploitation or susceptible to a given hazard."

Given these overlapping and interrelated definitions, they all reduce to a vulnerability affecting the security and stability of a computer system and posing a tangible risk to its users and its data. Because of this, there is a reasonable expectation that software vendors will provide updates to their products if that product is currently within the vendor's support lifecycle. For example, Microsoft is famous for their predictable and decades-old "Patch Tuesday" releases of security updates every second Tuesday of the month.

Characteristics of a Vulnerability: CVE

For security researchers, security practitioners, and technology vendors, a uniform nomenclature to publish, reference, and communicate information about vulnerabilities without confusing one another is vital. The Common Vulnerabilities and Exposures (CVE) Program was born to meet this need. Originally known as Common Vulnerability Enumeration (CVE), the naming system was created through a partnership with several different stakeholders. The initial idea for CVE was created via a research paper published by David E. Mann and Steven M. Christey of The MITRE Corporation and presented at Purdue University in 1999. With several participating organizations, including the Cybersecurity & Infrastructure Security Agency (CISA; reorganized from the National Cyber Security Division (NCSD) in 2018) of the DHS, which currently funds the program, CVE rapidly rose to prominence in the industry, with NIST recommending its usage via SP 800-51: "Use of the Common Vulnerabilities and Exposures (CVE) Vulnerability Naming Scheme" in 2002. The U.S. Defense Information Systems Agency (DISA) requires the usage of products and vendors that leverage the CVE program.

The format of a CVE identifier consistently follows the same pattern: CVE-YEAR-SEQUENCE_NUMBER. CVE identifiers (frequently referred to as simply "CVEs") are considered a universal reference for a unique vulnerability discovered in a particular product or family of products, such as Microsoft Windows and Microsoft Windows Server. CVEs are assigned by a CVE Numbering Authority (CNA) designated by MITRE Corporation. Many software vendors are CNAs for their own products, such as (not an exhaustive list):

Microsoft Corporation
Apple Inc.
CrowdStrike Holdings, Inc.
Hewlett-Packard (now two separate entities both acting as CNAs)
- Hewlett-Packard Enterprise (HPE)
- HP Inc.
Red Hat, Inc.
Etc.

Other organizations are CNAs in a broader sense because they evaluate a wide variety of products, research vulnerabilities in open-source software (OSS), or they participate in bounty programs (again, not an exhaustive list):

Amazon
Airbus
GitHub, Inc.
Anthropic, PBC
AppCheck Ltd.
Wiz, Inc.
Tenable Network Security, Inc.
Rapid7, Inc.
Automotive Security Research Group (ASRG)
Etc.

Ultimate authority over the CVE program resides with MITRE. The complete list of CVE Program Partners is publicly available on the CVE website.

Speaking of the CVE website, a very specific process, called the "CVE Record Lifecycle," is followed to register a new vulnerability in the CVE List in coordination with the researcher, the CNA, and the vendor of the affected product(s):

Discover – discovery of the vulnerability/flaw
Report – report the vulnerability discovery to a participant of the CVE program (like Microsoft or Bugcrowd, Inc.)
Request – the CVE program participant requests a new CVE identifier (CVE ID)
Reserve – reserve a new CVE Record, which is the definitive record of truth about the vulnerability identified by the CVE ID; this does not mean the CVE is published publicly yet. The participant or vendor may not be ready for public disclosure yet or may be awaiting an available fix.
Submit – the participant provides the details of the vulnerability (type, root cause, measured impact, and more that the CVE Record requires)
Publish – Coordinated public disclosure; the CVE Record is made public and is available for view/download

Here is a humorous example of a legitimately published vulnerability under the CVE program:

CVE-2022-38392: 5,400 RPM Hard Drives Resonant-Frequency Audio Attack Causes Denial of Service via Rhythm Nation Music Video

Certain models of 5,400 RPM Hard Disk Drives (HDD) found in various laptop and desktop computers from the Microsoft Windows XP era were vulnerable to Denial-of-Service (DoS) thanks to a hardware malfunction caused by the audio signal from globally recognized musical artist Janet Jackson's "Rhythm Nation" music video. Researchers found that an attacker with proximity to a computer equipped with one of these hard drives could crash the system because one of the drive's natural resonant frequencies was also contained in the song. Interestingly, MITRE itself issued this particular CVE.

For those unfamiliar, natural resonance is a phenomenon observed in physics where an object vibrates at a naturally occurring frequency. All objects in nature have one or more natural resonance frequencies determined by their physical characteristics. The hard drive's crash thanks to "Rhythm Nation" is akin to the same phenomenon that caused issues with the London Millennium Footbridge in 2000. The bridge was closed for modifications shortly after opening because of lateral sway produced by pedestrians' footsteps falling into a rhythmic pattern. This occurred because the natural walking frequency of most people closely matched the bridge's own lateral resonant frequency. The bridge remained closed for approximately two years while civil engineers reinforced it with dampers to reduce the sway.

The PC manufacturers mitigated the resonance issue by adding a software filter that removed the problematic frequencies from the audio signal. The likelihood of this CVE ever being a significant exploitability concern is practically zero, especially in 2026, as these affected drives would be approaching roughly two decades old and have most likely been trashed or recycled a long time ago. Still, this vulnerability is an entertaining example of what a published vulnerability looks like.

As seen in our Rhythm Nation example, vulnerabilities can be found in hardware as well as software, although hardware vulnerabilities are historically less common. Take CVE-2017-5754: Rogue Data Cache Load (a.k.a., "Meltdown"). This CVE details a scenario in which an unauthorized process can access areas of the computer's Random Access Memory (RAM) that are protected for the operating system (OS) kernel's (i.e., its "core") operations. Such sensitive areas can contain system-wide secrets like encryption keys and user passwords or hashes that unprivileged processes are not supposed to arbitrarily access without authorization. This happens because of an inherent design flaw in a performance feature of modern processors, or central processing units (CPUs), called speculative execution or "out-of-order" execution.

Speculative execution allows CPUs to perform instructions and store their results in the CPU's quick-access memory (called a cache) in advance of a program requiring them. In some scenarios, this feature can run instructions involving privileged system access before the program is authorized to do so, forcing a rollback of the executed instructions. However, even if the instructions are denied and the state of the CPU is rolled back, the results in the CPU's cache due to those instructions may still be there. If an attacker can access the cache, they can potentially read sensitive data from the system.

Hardware vulnerabilities are not as simple to protect against. Practically speaking, you can't simply "patch" or "update" what is a design flaw in the CPU's logic circuitry. Meltdown impacted all Intel-based CPUs on the x86 (32-bit) and x86_64/AMD64 (64-bit) architecture, IBM POWER CPUs, and some ARM-based CPUs (lots of smartphones use ARM CPU designs) that lacked hardware-level mitigations. Vendors such as Microsoft, IBM, Intel, ARM, Google, Red Hat, Canonical/Ubuntu, and many others provided updates at the OS and CPU microcode level to effectively mitigate the vulnerability in software. It's important to note a distinction here: a mitigation is not a fix; it's essentially a bandage to address the identified risk because remediating the issue is not feasible. The affected CPUs still have the flaw and are still inherently vulnerable, but the likelihood of the vulnerability being successfully exploited has been greatly reduced such that exploitation is impractical. Since Meltdown and the publication of similar processor-related flaws (e.g., Spectre v1, Spectre v2, ZombieLoad, Fallout, and so on), CPU makers have been researching better designs that will allow speculative execution optimizations and other CPU operations to function more safely.

Characteristics of a Vulnerability: CWE

Common Weakness Enumeration (CWE) is a categorical system for different types of hardware and software weaknesses. While a CVE uniquely identifies a vulnerability found within one or more products, CWEs tend to describe the nature of those vulnerabilities, which means CWEs are not unique to a particular vulnerability or product. For example, CWE-20: Improper Input Validation simply means the affected product receives input data but jumps straight into processing that data without making sure it's formatted correctly, or that the data doesn't appear malicious, or that the data is otherwise safe for handling. This is a common risk seen in websites/web applications that have form fields and URLs that allow for arbitrary input from users and can result in attacks like Cross-site Scripting (XSS) and SQL Injection (SQLi). As you can see, CWE-20 could affect thousands of software products if they do not perform input validation and sanitization. CWEs are more frequently the topic of discussion in the Application Security domain of cybersecurity.

In short, CVE and CWE are complementary programs both developed and maintained by MITRE: one for uniquely identifying vulnerabilities found in various products and the other describing the underlying weakness(es) using a common language. As such, one CWE can describe the nature and root cause of many CVEs.

Characteristics of a Vulnerability: CVSS & EPSS

In the cybersecurity field, practitioners, researchers, vendors, and organizations need a way to classify vulnerabilities based on their risk. One such method is the Common Vulnerability Scoring System (CVSS), currently at version 4 as of this writing. It was established by the National Infrastructure Advisory Council (NIAC) to be a common standard for measuring the severity of security vulnerabilities. The standard has since been developed and maintained by the Forum of Incident Response and Security Teams (FIRST), via their Special Interest Group (SIG), since version 2.

CVSS defines a set of standardized quantitative (calculated) metrics to provide a measure of the impact, called a score, a vulnerability has if it were to be exploited by a malicious actor, irrespective of the affected product or the vendor. This score is calculated on a scale from 0.0 to 10.0 with 10.0 being the highest severity (i.e., highest impact). Based on the CVSS score, a vulnerability can be assigned a qualitative rank such as None, Low, Medium, High, and Critical.

The factors used to calculate CVSS scores depend on the CVSS version you look at. CVSSv1 was first published in 2005, with CVSSv2 released to address "significant issues" in 2007. CVSSv3 was released in 2015 and CVSSv4 in 2023. The following is a list of the different metrics used across the CVSS standard, depending on the version used.

Base Metrics – Exploitability:

Access/Attack Vector (AV) – CVSSv1; changed over time from CVSSv2 through CVSSv3.x
Access/Attack Complexity (AC) – CVSSv1; changed over time from CVSSv2 through CVSSv4
Authentication (Au)/Privileges Required (PR) – CVSSv1 and CVSSv2; renamed from Au to PR and augmented in CVSSv3.x
User Interaction (UI) – CVSSv3.x; augmented in CVSSv4
Scope (S) – only CVSS 3.x; replaced in CVSSv4
Impact Bias – only CVSSv1; removed in CVSSv2

Base Metrics – Impact:

Confidentiality (C)
Integrity (I)
Availability (A)
Subsequent System Confidentiality (SC) – added in CVSSv4
Subsequent System Integrity (SI) – added in CVSSv4
Subsequent System Availability (SA) – added in CVSSv4

Temporal (Threat) Metrics:

Exploitability (CVSSv1 and CVSSv2)/Exploit Code Maturity (CVSSv3.x)/Exploit Maturity (CVSSv4)
Remediation Level – augmented in CVSSv2 and CVSSv3.x; removed in CVSSv4
Report Confidence – augmented in CVSSv2 and CVSSv3.x; removed in CVSSv4

Environmental Metrics:

Collateral Damage Potential (CDP) – added in CVSSv1; augmented in CVSSv2; removed in CVSSv3.x
Target Distribution (TD) – added in CVSSv1; augmented in CVSSv2; removed in CVSSv3.x
Confidentiality Requirement (CR) – added in CVSSv2; augmented in CVSSv3.x
Integrity Requirement (IR) – added in CVSSv2
Availability Requirement (AR) – added in CVSSv2
Modified Base Metrics – added in CVSSv3.x; significantly augmented in CVSSv4

Supplemental Metrics (CVSSv4 only):

Safety (S)
Automatable (AU)
Provider Urgency (U)
Recovery (R)
Value Density (V)
Vulnerability Response Effort (RE)

As you can see, the CVSS standard uses several characteristics of a vulnerability to calculate scores. I won't dive into the mathematical formulas that underpin the score calculations, as they gradually get more complex with each iteration of CVSS. Detailed documentation on the subject can be found on FIRST's website for those who are interested. The takeaway is that CVSS measures impact if a vulnerability gets exploited. What CVSS's scores do not tell us is whether a given vulnerability represents a credible, imminent exploitable risk. That is where EPSS comes into play.

The Exploit Prediction Scoring System (EPSS) is a complementary model to CVSS. Whereas CVSS measures impact (i.e., severity) of a vulnerability using statically defined formulas, EPSS actually uses Machine Learning (ML) algorithms to measure the probability (i.e., likelihood) of a vulnerability being exploited in the real world in the first 30 days after the vulnerability has been published, using a decimal range between 0 and 1 (i.e., 0% to 100%). EPSS was initially published by FIRST in 2021 and as of 2025 is at version 4, adding contextual data provided by cyber threat intelligence.

EPSS has a wide set of factors it evaluates using ML, including but not limited to:

Attack complexity
Affected product popularity/install base
Threat intelligence and community reports
Days since vulnerability publication
CVSS metrics (yes, CVSS metrics can also be an input to EPSS calculations)
Known exploit payloads, proof-of-concept code, or a published Metasploit module

EPSS is not intended to replace CVSS. On the contrary, EPSS is intended to complement CVSS by allowing organizations to prioritize what to fix/patch first in their computer environments to prevent security incidents in the first place.

Patch Quickly, Patch Often

Now that we understand how the security industry approaches vulnerabilities, why should you care? For one thing, many consumer-grade products have just as many vulnerabilities as enterprise or commercial-grade hardware and software. Take Microsoft's July 2026 Patch Tuesday. That month, Microsoft fixed a staggering 622 unique vulnerabilities, with 416 of those vulnerabilities affecting the Windows product family alone. This figure does not include republished CVEs for Microsoft's Edge web browser that uses The Chromium Project's browser core, the same underlying software architecture also used by Google's Chrome browser (note The Chromium Project is sponsored by Google). Speaking of Google Chrome, on June 30th, 2026, Google fixed an enormous 433 CVEs in their browser with 20 being rated "Critical." An additional 370 CVEs were patched in a subsequent July 2026 release.

For you gamers, you'll probably find it humorous that a remote-code execution (RCE) CVE was found in Age of Empires II: Definitive Edition, a game originally published in 1997. The vulnerability could be exploited through processing malicious game scenario files. Apparently, some attackers have a bit too much of an interest in targeting real-time strategy (RTS) players.

For you Apple iPhone and iPad fans, the Cupertino-based firm released an update on August 17th, 2026 to address well over 100 identified CVEs, several with a "Critical" CVSS score assigned.

All these examples are just the tip of the iceberg. With advances in AI, more vulnerabilities are being found much more quickly in more products than ever before. To protect yourself, your devices, and your data, it is paramount that you apply updates as soon as they are made available. For consumers, it is strongly recommended to ensure all devices and software are configured to automatically download and apply updates. However, you can use the following guidance to double-check that you are up to date. Please note that technology frequently changes, and while this guidance is accurate as of this writing, it may become outdated in the future. When in doubt, always refer to the software or device vendor's official documentation or reach out to their support resources if you are still having trouble. Lastly, before applying updates, running commands, or making any configuration changes to your devices, make sure they are properly backed up.

Updates to Microsoft Windows

The fastest way to update Windows would be by searching for "update" in the search bar. This should bring up the relevant section in the Settings app on Windows 11. Ensure you apply the latest updates and fully reboot. If you are on an earlier version of Windows (e.g., 10, 8/8.1, 7, Vista, XP, etc.), it is not recommended to remain on these unsupported operating systems.

Note that while mainstream Windows 10 support ended in October 2025, Windows 10 personal (i.e., consumer-grade) users with paid Extended Security Updates (ESU) support will have updates available through October 2027. If you are running Windows 10 and you do not have an ESU subscription, it is strongly recommended you migrate to Windows 11 to continue receiving security updates for your device.

Reference: https://support.microsoft.com/en-US/Windows/Deployment/Updates-Lifecycle/install-windows-updates

Updates to Apple macOS (previously known as Mac OS or Mac OS X)

Use the System Settings app to check for Software Updates. Like Windows, ensure you allow the device to fully reboot.

Reference: https://support.apple.com/en-us/108382

Updates to Debian Linux and derivatives (Ubuntu, Linux Mint, Kubuntu, Xubuntu, Ubuntu MATE, Ubuntu Studio, elementaryOS, Pop! OS, and many others using the Debian base)

Because of the wide variety of desktop environments and package managers across the Linux and open-source ecosystem, this process will heavily depend on your individual OS installation and configuration, including what software packages you have installed. Assuming you are running the standard Ubuntu OS with the GNOME desktop environment, open the Software Updater, allow it to query the Ubuntu software repositories, apply the updates, and then reboot. An arguably easier way across all Debian/Ubuntu variants would be to open a Terminal program to access the command-line and run the following commands:

sudo apt update && sudo apt upgrade

These commands will refresh the package lists from your OS's repositories and then begin applying all the available package updates. As stated before, ensure you fully reboot, especially if a Linux kernel update has been applied. Note that these commands run using the sudo command, meaning they must run with privileges. Your user must be configured with permission to use sudo.

Linux distributions that are not Debian-based (e.g., Fedora, Red Hat, Arch, etc.) have similar graphical and command-line update mechanisms. Refer to your distribution's documentation for specifics on how to apply updates.

References: https://ubuntu.com/desktop/docs/en/latest/how-to/upgrade-ubuntu-desktop/

Updates to Apple iOS, iPadOS, watchOS, tvOS, and visionOS

Like the process on macOS, use the Settings app on your device to check for updates and apply them accordingly. For watchOS, the operating system that powers the Apple Watch, you will need to ensure your iPhone and your Apple Watch are on their chargers and within range of each other. Use the Watch app on your iPhone to check for and apply watchOS updates (it's a very similar process to applying iOS and iPadOS updates).

References:

Updates to Microsoft Edge, Google Chrome, Mozilla Firefox, and Opera browsers

These web browsers can be updated by launching the browser, navigating the menu, and going to the "About" page. This typically shows the current browser version along with an automated check for updates. Allow the browser to download the update and make sure you restart the browser to ensure the update took full effect. Note that for Chrome and Firefox on Linux desktop environments, you may need to run an update command to pull the update.

References:

Updates to Apple Safari

Typically, Safari updates are bundled into the OS update if you are running the latest release of macOS (26.6.2 "Tahoe" as of this writing). If you are running an older but still supported macOS release (15.7.9 "Sequoia" and 14.8.9 "Sonoma" as of this writing), you will see a separate update listed for Safari in your System Settings app.

Note that Safari updates on iOS and iPadOS are always bundled into the device's OS updates.

Updates to Microsoft Office Apps (Office for Windows and Microsoft 365)

For users of Microsoft's productivity suite in either standalone license or subscription forms, the apps are updated in a similar manner to web browsers where the next launch of one of the apps in the suite will eventually kick off the update process. If you don't wish to wait, open any one of your apps, navigate to File, Account, Microsoft 365 and Office Updates, and click the Update Now button.

If you are running Office apps on a Mac, check the Mac App Store app for updates to your Office apps. If you downloaded the Microsoft Office for Mac installer from Microsoft directly, open one of the apps, and in the top menu navigate to Help, then click Check for Updates.

References:

A lot of other 3rd party software has an update mechanism found somewhere in its settings or preferences menus. As you can imagine, this process can wildly vary. Refer to the software's documentation and user guides from the software vendor for details.

Admittedly, this post was a bit of a deep dive for a casual reader, but for those interested in how bugs, vulnerabilities, and software updates relate to one another, I think managed to touch on all the important points.

References

The First Computer Bug

Edison, T.A. (1878, March 10). Letter to William Orton, President of Western Union. Archived in: Israel, P.B., Nier, K., & Carlat, L. (Eds.). (1998). The Papers of Thomas A. Edison: The Wizard of Menlo Park, 1878. Johns Hopkins University Press.

Smithsonian National Museum of American History. (1947/1994). Log Book With Computer Bug [artifact, catalog no. 1994.0191.01]. Smithsonian Institution, Washington, D.C. https://www.si.edu/object/log-book-computer-bug:nmah_334663

Hopper, G.M. (1981). The First Bug. Annals of the History of Computing, 3(3), 285–286.

Kidwell, P.A. (1998). Stalking the Elusive Computer Bug. IEEE Annals of the History of Computing, 20(4), 5–9.

When a Bug Becomes a Security Concern

Committee on National Security Systems. (2022). CNSSI No. 4009: Committee on National Security Systems (CNSS) Glossary (Rev. ed.). National Security Agency. https://www.cnss.gov/CNSS/issuances/Instructions.cfm

National Institute of Standards and Technology. (2012). Guide for Conducting Risk Assessments (NIST Special Publication 800-30 Rev. 1). U.S. Department of Commerce. https://doi.org/10.6028/NIST.SP.800-30r1

Microsoft. Update Tuesday (Patch Tuesday). Microsoft Security Response Center. https://msrc.microsoft.com/update-guide

Characteristics of a Vulnerability: CVE

Mann, D.E., & Christey, S.M. (1999). Towards a Common Enumeration of Vulnerabilities. Paper presented at the 2nd Workshop on Research with Security Vulnerability Databases, Purdue University, West Lafayette, IN. MITRE Corporation.

MITRE Corporation. CVE® Program. https://www.cve.org

MITRE Corporation. CVE Record Lifecycle. CVE Program. https://www.cve.org/ResourcesSupport/AllResources/CNARules

Mell, P., & Grance, T. (2002). Use of the Common Vulnerabilities and Exposures (CVE) Vulnerability Naming Scheme (NIST Special Publication 800-51). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-51

U.S. Defense Information Systems Agency. Security Technical Implementation Guides (STIGs). https://public.cyber.mil/stigs

National Vulnerability Database. (2022). CVE-2022-38392 Detail. National Institute of Standards and Technology. https://nvd.nist.gov/vuln/detail/CVE-2022-38392

Chen, R. (2022, August 16). Janet Jackson had the power to crash laptop computers. The Old New Thing [blog]. Microsoft Developer Blogs. https://devblogs.microsoft.com/oldnewthing/20220816-00/?p=106994

Dallard, P., Fitzpatrick, A., Flint, A., Le Bourva, S., Low, A., Ridsdill Smith, R., & Willford, M. (2001). The London Millennium Footbridge. The Structural Engineer, 79(22), 17–33.

Strogatz, S.H., Abrams, D.M., McRobie, A., Eckhardt, B., & Ott, E. (2005). Crowd synchrony on the Millennium Bridge. Nature, 438, 43–44. https://doi.org/10.1038/438043a

Lipp, M., Schwarz, M., Gruss, D., Prescher, T., Haas, W., Fogh, A., Horn, J., Mangard, S., Kocher, P., Genkin, D., Yarom, Y., & Hamburg, M. (2018). Meltdown: Reading kernel memory from user space. In Proceedings of the 27th USENIX Security Symposium (pp. 973–990). USENIX Association. https://meltdownattack.com/meltdown.pdf

National Vulnerability Database. (2018). CVE-2017-5754 Detail. National Institute of Standards and Technology. https://nvd.nist.gov/vuln/detail/CVE-2017-5754

Characteristics of a Vulnerability: CWE

MITRE Corporation. Common Weakness Enumeration (CWE). https://cwe.mitre.org

MITRE Corporation. CWE-20: Improper Input Validation. Common Weakness Enumeration. https://cwe.mitre.org/data/definitions/20.html

Characteristics of a Vulnerability: CVSS & EPSS

FIRST (Forum of Incident Response and Security Teams). (2005). Common Vulnerability Scoring System (CVSS) v1 Complete Guide. https://www.first.org/cvss/v1/guide

FIRST. (2007). Common Vulnerability Scoring System (CVSS) v2 Complete Guide. https://www.first.org/cvss/v2/guide

FIRST. (2019). Common Vulnerability Scoring System (CVSS) v3.1: Specification Document. https://www.first.org/cvss/v3.1/specification-document

FIRST. (2023). Common Vulnerability Scoring System (CVSS) v4.0: Specification Document. https://www.first.org/cvss/specification-document

Jacobs, J., Romanosky, S., Edwards, B., Adjerid, I., & Roytman, M. (2021). Exploit Prediction Scoring System (EPSS). Digital Threats: Research and Practice, 2(3). https://doi.org/10.1145/3436242

FIRST. Exploit Prediction Scoring System (EPSS). https://www.first.org/epss

Patch Quickly, Patch Often

Rapid7. (2026, July 14). Patch Tuesday – July 2026. Rapid7 Blog. https://www.rapid7.com/blog/post/em-patch-tuesday-july-2026/

Google. (2026). Chrome Releases Blog. Google. https://chromereleases.googleblog.com/

Apple. (2026, August 17). Apple security releases. Apple Support. https://support.apple.com/en-us/100100

Update Instructions

Microsoft. Install Windows updates. Microsoft Support. https://support.microsoft.com/en-US/Windows/Deployment/Updates-Lifecycle/install-windows-updates

Apple. Update macOS on Mac. Apple Support. https://support.apple.com/en-us/108382

Canonical/Ubuntu. How to upgrade Ubuntu Desktop. Ubuntu Documentation. https://ubuntu.com/desktop/docs/en/latest/how-to/upgrade-ubuntu-desktop/

Apple. Update iOS on iPhone. Apple Support. https://support.apple.com/en-us/118575

Apple. Update iPadOS on iPad. Apple Support. https://support.apple.com/en-us/108926

Apple. Update Apple Watch software (watchOS). Apple Support. https://support.apple.com/en-us/108414

Apple. Update Apple TV software (tvOS) and visionOS. Apple Support. https://support.apple.com/en-us/118481

Microsoft. Getting the latest Microsoft Edge update just got easier. Microsoft Support. https://support.microsoft.com/en-us/edge/getting-the-latest-microsoft-edge-update-just-got-easier

Google. Update Google Chrome. Google. https://www.google.com/chrome/update/

Mozilla. Update Firefox to the latest release. Mozilla Support. https://support.mozilla.org/en-US/kb/update-firefox-latest-release

Opera. Opera FAQ. Opera Help. https://help.opera.com/en/faq/

Microsoft. How to update Microsoft 365 or Office for Windows. Microsoft Support. https://support.microsoft.com/en-us/office/lifecycle/officeinstall/how-to-update-microsoft-365-or-office-for-windows

Microsoft. Update Office for Mac automatically. Microsoft Support. https://support.microsoft.com/en-us/office/lifecycle/officeinstall/update-office-for-mac-automatically

Note: several of the above are living pages and may be updated/changed after this post's publication date.