# Joint-review Outline

This joint-review is built on top of the four self-assessment for the Argo projects

[Argo CD](self-assessment.md)

[Argo Rollouts](self-assessment.md)

[Argo Workflows](self-assessment.md)

[Argo Events](self-assessment.md)

# Joint-review of [ArgoProj](https://argoproj.github.io/)

## Table of Contents

* [Metadata](#metadata)
* [Security links](#security-links)
* [Overview](#overview)
* [Background](#background)
* [Goals](#goals)
* [Non-goals](#non-goals)
* [Joint-review use](#joint-review-use)
* [Intended use](#intended-use)
* [Project design](#project-design)
* [Functions and features](#functions-and-features)
* [Security functions and features](#security-functions-and-features)
* [Configuration and set-up](#configuration-and-set-up)
* [Project compliance](#project-compliance)
* [Security analysis](#security-analysis)
* [Secure development practices](#secure-development-practices)
* [Security issue resolution](#security-issue-resolution)
* [Closed security issues and vulnerabilities](#closed-security-issues-and-vulnerabilities)
* [Hands-on review](#hands-on-review)
* [Roadmap](#roadmap)
* [Appendix](#appendix)

## Metadata
Argo (aka Argoproj) is an umbrella project that consists of four individual projects and repositories, which may be used together, or independently.
|Area|URL|
| -- | -- |
|Software|[Argo CD](https://github.com/argoproj/argo-cd)|
||[Argo Rollouts](https://github.com/argoproj/argo-rollouts)
||[Argo Workflows](https://github.com/argoproj/argo-workflows)
||[Argo Events](https://github.com/argoproj/argo-events) |
|Security Provider | No |
|Languages | Golang, Typescript, Lua |
|SBOMs| SBOMs are automatically generated for each release for all projects under https://github.com/argoproj/<project>/releases/download/<version>/sbom.tar.gz |

### Security links

Security Documentation.
| Doc | URL |
| -- | -- |
|Argo CD|https://argo-cd.readthedocs.io/en/stable/operator-manual/security/|
|Argo Rollouts|https://argoproj.github.io/argo-rollouts/security/|
|Argo Workflows|https://github.com/argoproj/argo-workflows/blob/master/docs/security.md|
|Argo Events|https://github.com/argoproj/argo-events/blob/master/SECURITY.md|

## Overview

Argo is a set of Kubernetes-native tools for running and managing jobs and applications on Kubernetes. This is exemplified by the Argo tagline, "Get stuff done with Kubernetes!"
Argo makes it easy to combine workflows, events and deployments to declaratively create jobs and applications on Kubernetes.

[Argo Workflows](https://github.com/argoproj/argo-workflows) - Container-native Workflow Engine

[Argo CD](https://github.com/argoproj/argo-cd) - Declarative GitOps Continuous Delivery

[Argo Rollouts](https://github.com/argoproj/argo-rollouts) - Declarative Progressive Delivery and Experimentation

[Argo Events](https://github.com/argoproj/argo-events) - Event-based Dependency Manager

### Background

Argo consists of four projects under the Argo umbrella, which has been an incubating project in CNCF since April 2020. The projects share some similarities and technologies but are all stand-alone projects that can be used separately, or together. They all share the philosophy of being loosely coupled building blocks that can be put together, or seamlessly integrated into other platforms, and a number of other open source projects include, or integrate with, Argo projects, e.g. Backstage, Kubeflow Pipelines and Couler.

The Argo projects are currently used by over 300 companies, across geos and industry verticals and have over 3800 contributors.

### Project Goals

* All Argo projects are cloud native and based on Kubernetes.

* Argo CD enables resource management in multiple Kubernetes clusters while enforcing restrictions configured by the administrator.

* Argo Events enables triggering of K8s objects, Argo Workflows, Serverless workloads, etc. on events from a variety of sources through an event-driven workflow automation framework

* Argo Rollouts enables advanced deployment capabilities such as blue-green, canary, canary analysis, experimentation, and progressive delivery features

* Argo Workflows enables large scale orchestrated Kubernetes jobs to support Machine Learning pipelines, ETL and Data and batch processing.

### Project Non-goals

* Argo CD does not solve config management problems. Instead, it integrates various config management tools such as Helm, Kustomize, and Jsonnet.
* Argo CD does not provide secret management features. Instead, it is suggested to use existing secret management projects for Kubernetes such as
[kubernetes-external-secrets](https://github.com/external-secrets/kubernetes-external-secrets) or [sealed-secrets](https://github.com/bitnami-labs/sealed-secrets).

* Argo workflows does not intend to be a full Infrastructure automation or CI/CD platform, but will remain a building block for anyone who needs a workflow component in their platform.
> [name=Michael Crenshaw]clarify that Argo CD uses Kubernetes to provide these features
does not intend
## Joint-review use

The joint-review is initially created by the project team and then collaboratively developed with the [security reviewers](security-reviewer.md) as part of the project's TAG-Security Review (formerly called security assessment). Information about the TAG-Security Review can be found in the [CNCF TAG-Security Review Process Guide](https://github.com/cncf/tag-security/blob/main/assessments/guide/security-reviewer.md).

This document does not intend to provide a security audit of Argo and is not intended to be used in lieu of a security audit. This document provides users of Argo with a security focused understanding of Argo and when taken with the self assessments provide the community with the TAG-Security Review of the project. Both of these documents may be used and references as part of a security audit.

## Intended Use

The intended use of Argoproj is to provide cloud native tools to manage and deploy kubernetes resources. Argo CD and Argo Rollouts focus more on managing resources and applications through GitOps, while Argo Workflows and Events provide workflow and event capabilities for MLOps.

## Target Users and Use Cases

Per the Security TAG user personas, Argoproj serves the needs of:

* **Developer**: All Argo projects provide tools that help developers deploy and manage their deployed Kubernetes objects. Argo CD uses a declared state in a git or Helm repo to update and keep track of the state of managed resources and makes sure they are in sync. Argo Rollouts extends the Kubernetes Deployment object to provide additional advanced deployment capabilities that allow developers to deploy faster and with lower risk by utilizing blue/green or canary strategies.
Argo Workflows provides a massively scaling workflow orchestration engine that can be used by ML developers, data scientists/engineers to define parallel workflows for ML and data pipelines.
Argo events enables developers, SREs, DevOps to set up depencies on a variety of sources and trigger events when certain conditions are met.
* **Platform Implementer**: A platform implementer can use the Argo projects as building blocks to compose cloud native platforms that provide application and resource management to their developers, or ML pipelines or data plaforms to their data engineers and scientists.

### Target Capabilities

> What kinds of things are meant to go here? Answer from Dan: need more threat modeling to know. [name=Michael Crenshaw]

| Capability | Type | Description |
| -- | -- | -- |
|Foo | Bar | Boo |

### Operations

Argoproj operations

## Project Design

* Design. A description of the system design that discusses how it works. This
is especially critical for any mechanisms that relate to the security of the system. Include architecture and network (if applicable) information such as encryption of traffic between services, access control types (RBAC, etc.) and enforcement, or security logging, etc.

### Data flow diagram/Architecture diagram

Argo CD
> [name=Michael Crenshaw]Need to define threat boundaries (i.e. boxes in the diagram).
> Need to think through all the different *interactions* a user is going to have with Argo CD.
> Describe how each pod connects to another.

Argo Events

> [name=Michael Crenshaw]Lines need details. What protocol, is it encrypted, etc.

Argo Rollouts

Argo Workflows

### Functions and features

* Critical. A listing with brief description of functions and features that are critical to the project's ability to meet its intended use. It is recommended these be covered in the threat model.
* Relevant. A listing with brief description of the functions and features of the project that perform a security relevant function. It is recommended these be covered in the threat model.

#### Security functions and features

##### Argo CD

* Critical. **RBAC:** Argo CD leverages the [https://github.com/casbin/casbin](https://github.com/casbin/casbin) project to implement declarative
role-based access control. The administrator manages casbin policies to configure actions permitted to the OIDC claims.
* Critical. **SSO integration:** Argo CD allows connecting to OIDC-compliant SSO providers and uses “claims” stored in the generated JWT token
to authorize user actions.
* Critical. **System Accounts:** Argo CD supports built-in system accounts that are used to access Argo CD API to automate management tasks.
* Critical. **Kubernetes RBAC Manifests:** The Argo CD deployment model uses Kubernetes RBAC to support granular namespace and cluster-level isolation
for controlling the level of influence an Argo CD user may have with management of user workloads on a Kubernetes cluster.
* Security Relevant. **Kubernetes Network Policies:** The recommended Argo CD deployment model configures out-of-the-box Network policies that manage
traffic between Argo CD components.
* Critical. **Lua Health Checks**: The Argo CD uses Lua scripts to support adding health assessment scripts for CRDs. By default Lua scripts are not
allowed to use the standard library and so don’t have access to IO or any other “dangerous” operations. The Argo CD administrator might enable the
standard library access after reviewing the Lua script.
* Critical. **AppProjects:** Argo CD has a CRD called AppProject which restricts sources of truth and destinations for Applications. Each Application must be grouped under an AppProject. A misconfigured AppProject may allow an attacker to deploy manifests which are not properly restricted (for example, from a git repo without proper review rules) or to a destination which should not be allowed (for example, a prod cluster when only non-prod should be allowed).
* Critical. **Self-service Argo CD config:** Argo CD can deploy Applications and AppProjects as resources in Applications. Since those resources contain security-sensitive information, Apps-of-Apps and Apps-of-Projects require additional care which is not required for Applications which deploy other types of resources. Admins must also be careful to avoid intuitive but incorrect assumpations about App-of-App/Project behavior. For example, Apps deployed by a parent App _do not_ inherit the parent App's `project` restriction - that must be enforced by some other mechnanism. ApplicationSets are also often used as a "self-service" way to deploy Applications (for example, via git generators or SCM generators). ApplicationSets must be restricted to prevent untrusted modifications of security-sensitive Application fields (like `spec.project` or `spec.source`).
* Relevant. **Understanding access level for different roles:** Modifying Applications and especially AppProjects is a security-sensitive capability. Organizations often find they need to grant that access to support personnel. It's important to make sure those personnel understand the implications of changes they may make to those resources. They need training in Argo CD's security controls so they do not accidentally make a damaging change. Having an audit trail (for example via GitOps) can help find and remedy misconfigurations.
* Relevant. **Default project:** The `default` AppProject which ships with Argo CD has no restrictions by default. Failing to add restrictions may lead users to continue to use the unrestricted AppProject simply because it exists. Users should either restrict this `default` AppProject or make sure there are guidelines in place to make sure Applications use different (restricted) AppProjects.
* Relevant. **GitOps provides audit/review controls:** Even with strong AppProject and RBAC restrictions in place, manifests can be security-sensitive resources. Fully adoping a GitOps workflow provides an audit trail (via git commits) and a review mechanism (via branch restrictions in git) to make sure only safe resources make it to the cluster. Adopting GitOps in as many places as possible makes sure those benefits are available.
* Relevant. **Argo CD does _not_ enforce GitOps:** Argo CD is pragmatic. You can choose to do things in a very strictly-GitOps manner. Or you can take advantage of less strictly-GitOps features. To get the full benefits of GitOps, it's important to restrict the features which allow non-GitOps behavior (like editing resources directly via the UI) when appropriate. For example, those mechanisms might be reserved for admin staff only.

##### Argo Workflows

* Critical. **SSO integration**: Argo workflow allows connecting to OIDC-compliant SSO providers and uses “claims” stored in the generated JWT token to authorize user actions.
* Critical. **System Accounts**: Argo workflow supports built-in system accounts that are used to access Argo CD API to automate management tasks.
* Critical. **Kubernetes RBAC Manifests**: The Argo workflow deployment model uses Kubernetes RBAC to support granular namespace and cluster-level isolation for controlling the level of influence an Argo Workflow user may have with management of user workloads on a Kubernetes cluster.

## Configuration and Set-Up

* Default. Documentation describing the default configuration of the project with initial set-up instructions (link to docs is acceptable). Documentation should identify potential security risks/trade-offs of the default config.
* Secure. Documentation describing recommended secure configuration and set-up
instructions, beyond defaults with justification for selection and trade-offs (link to docs is acceptable).
* Advanced Secure. If applicable, documentation describing advanced settings for
most hardened configuration of the project to include justification for selection and trade-offs (link to docs is acceptable).

### Argo CD

* Default. The [Argo CD getting started guide](https://argo-cd.readthedocs.io/en/stable/getting_started/) shows how to set up a default Argo CD instance and points out that the user should reset the initial randomly-generated password.
* Secure. The [security section](https://argo-cd.readthedocs.io/en/stable/operator-manual/security/) of the operator manual describes the default behavior of security-relevant components and points to more advanced information. The [RBAC page](https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/) describes how to define Argo CD RBAC rules. The [project](https://argo-cd.readthedocs.io/en/stable/user-guide/projects/) page describes how to restrict Application gitops capabilities.
* Advanced secure. There are advanced [hardening instructions](https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Security/) for users of the ApplicationSets component.

> [name=Michael Crenshaw]We need these for the other 3 projects. Also probably more detail on Argo CD.

> [name=Michael Crenshaw]Discuss at a high level different _types_ of setups and their different security concerns. For example, talk about tenancy. Should also have notes about apps-of-(apps/projects) and applicationsets and the security implications of using them.

## Project Compliance

Not applicable.

> [name=Michael Crenshaw] This section is about this: https://github.com/cncf/tag-security/blob/main/assessments/guide/joint-review.md#project-compliance

### Existing Audits

* [Trail of Bits (March 12, 2021)](https://github.com/argoproj/argoproj/blob/master/docs/argo_security_final_report.pdf)
* [Ada Logics (July 18, 2022)](https://github.com/argoproj/argoproj/blob/master/docs/argo_security_audit_2022.pdf)
* [Fuzzing (February 25, 2022)](https://github.com/argoproj/argoproj/blob/master/docs/audit_fuzzer_adalogics_2022.pdf)

## Security Analysis

### Threat Actors

|Actor|Description|
| -- | -- |
| Malicious Internal | A user such as an administrator or developer who uses stolen credentials or a privileged position maliciously against the system.
| Internal Attacker | An attacker who has transited one or more trust boundaries, such as an attacker with container access.
| External | An attacker who is external to the cluster and unauthenticated—for example, a developer who did not contribute to Argo products directly but worked on dependencies included in Argo services or end user repositories.
| Administrator | An actual administrator of the Argo service tasked with operating and maintaining the internal cluster as a whole.
| End User | The end user of the Argo service.

> [name=Michael Crenshaw]Need some more actors, more detailed actors.

### Attacker Motivations

**Argo CD**

Matrix:

| | manifest git repo push access but no sync access | manifest git repo push access plus sync access | Application local sync access | Application edit access |
| -- | -- | -- | -- | -- |
| No review required before pushing resource manifest changes to git, and resources are not synced | **No impact.** Malicious resources pushed to the git repo are not applied to the destination cluster. | **Resources are restricted only by the AppProject.** Malicious resources pushed to the git repo may be synced by the malicious user. | **Resources are restricted only by the AppProject.** The user could already bypass git and apply resources with `argocd app sync --local`. | **Resources are restricted only by the AppProject.** The malicious user can enable auto-sync on the Application and cause their resources to be applied.
| No review required before pushing resource manifest changes to git, and resources are synced | **Resources are restricted only by the AppProject.** Malicious resources pushed to the git repo are applied to the Application's destination cluster. This can happen either because auto-sync is enabled, or the person triggering the sync fails to sufficiently review the resource changes. | User already had more access than this by writing manifests directly to Application with `argocd app sync --local`, bypassing git. | User can already bypass review requirement by changing App source to one without review requirement (unless that source is blocked by AppProject). | N/A - user can remove all restrictions for an AppProject and take over Argo CD security config. |
| AppProject does not restrict source repos | N/A - just having push access to a manifest repo doesn't necessarily mean you can deploy something malicious. | N/A - user can bypass source anyway. | User can change the Application's source repo to something relatively unrestricted (for example, no review requirement). |
| AppProject edit access |

> [name=Michael Crenshaw]Needs another column tying each row to _where_ in the architecture the row applies. Need a structured description of an architecture to do that.

Actors:

|Actor|Threat|
| -- | -- |
| Malicious Internal | Malicious internal users are often privileged and have access to a wide range of resources, such as the Kubernetes cluster that hosts Argo Infrastructure. Therefore, for strong non-repudiation of actions, controls must be in place to ensure that users are authorized to undertake an action, as well as to log all actions within the system. |
| Administrator | Administrators may misconfigure Argo services such that they do not allow users to deploy their target infrastructure as expected. To mitigate such concerns, errors in the system should be logged accordingly to provide an audit trail alongside extensive administrator documentation. |
| End User | End users may misconfigure their repositories in a way that prevents their target infrastructure from deploying as expected. To mitigate such concerns, errors in the system should be logged accordingly to provide an audit trail alongside extensive user documentation.
| Internal Attacker | An internal attacker could modify the Web UI code served to the end user by argocd-server and force the end user’s browser to execute a malicious payload.
| Internal Attacker | An internal attacker could leverage access to a component in Argo infrastructure to move laterally and gain access to other components. Such an attacker may also be able to extract Kubernetes secrets meant for other components due to a lack of isolation. |
| Internal Attacker | An internal attacker could gain access to the VCS and change underlying infrastructure managed by Argo CD via pull requests/commits that modify relevant manifests.
| Internal Attacker | An internal attacker could leverage access to Argo infrastructure to clone repositories that would otherwise be inaccessible to the attacker. The attacker may be able to extract Kubernetes secrets such as repository SSH keys, allowing the attacker greater access to underlying repositories.
| Internal Attacker | An internal attacker could leverage access to the Argo infrastructure to control target infrastructure deployments; the attacker could also potentially change policies for users or allow himself or herself to override syncs from their local machine instead of the VCS. |
| External Attacker | An external attacker may try to leverage API calls to look for vulnerabilities within the system. Appropriate auditing and logging procedures should be implemented to ensure that administrators can follow an audit trail to understand and mitigate attempted attacks.
| External Attacker | An external attacker may be a developer of dependencies used by Argo CD or user repositories. The attacker may execute a supply chainattack that gains control of Argo infrastructure or may target the end user’s target infrastructure.

**Argo Events**
|Actor|Threat|
| -- | -- |
| Malicious Internal User | Malicious internal users are often privileged and have access to a wide range of resources, such as the Kubernetes cluster that hosts Argo infrastructure. Therefore, for strong non-repudiation of actions, controls must be in place to ensure that users are authorized to undertake an action, as well as to log all actions within the system. |
| External Attacker | An external attacker may be able to attack a trigger destination to cause a message delivery failure. If the trigger destination endpoint is unavailable, the event will fail to send to the endpoint. Based on user configuration, it may retry sending a number of times, but the event may ultimately be lost permanently.
| External Attacker | An external attacker may be able to control an event origin and affect availability, causing event source pods to fail to fetch events. Additionally, the attacker may be able to control or generate event data that can exhaust the resources of Argo Events, resulting in a denial of service
| End User | Argo infrastructure may log to a number of external logging providers. End users may misconfigure theirlogging providers. End users should be provided extensive user documentation, which may help alleviate such concerns.

**Argo Rollouts**
|Actor|Threat|
| -- | -- |
| Malicious Internal User |Malicious internal users are often privileged and have access to a wide range of resources, such as the Kubernetes cluster that hosts Argo infrastructure. Therefore, for strong non-repudiation of actions, controls must be in place to ensure that users are authorized to undertake an action, as well as to log all actions within the system. |
| Administrator / End User |End users in this system are also administrators. In this case, the Argo infrastructure modifies the underlying service mesh. End users may misconfigure their service meshes, preventing their rollouts from working as expected. To mitigate such concerns, errors in the system should be logged accordingly to provide an audit trail alongside extensive user documentation. |
| Administrator / End User |End users in this system are also administrators. In this case, the Argo infrastructure logs to a number of potential logging providers. End users may misconfigure their logging providers. End users should be provided extensive user documentation, which may help alleviate such concerns. |

**Argo Workflows**
|Actor|Threat|
| -- | -- |
| Malicious Internal User | Malicious internal users are often privileged and have access to a wide range of resources, such as the Kubernetes cluster that hosts Argo infrastructure. Therefore, for strong non-repudiation of actions, controls must be in place to ensure that users are authorized to undertake an action, as well as to log all actions within the system. |
| Administrator | Administrators may misconfigure Argo services such that they do not allow users to deploy their workflow infrastructure as expected. To mitigate such concerns, errors in the system should be logged accordingly to provide an audit trail alongside extensive administrator documentation. |
|End User| End users may misconfigure their repositories in a way that prevents their workflow infrastructure from deploying as expected. To mitigate such concerns, errors in the system should be logged accordingly to provide an audit trail alongside extensive user documentation.|
| Internal Attacker| An internal attacker could leverage access to a component in Argo infrastructure to move laterally and gain access to other components. Such an attacker may also be able to extract Kubernetes secrets meant for other components due to a lack of isolation.|
| Internal Attacker| An internal attacker could extract Kubernetes secrets to connect to external logging providers, affecting the integrity or availability of logs.
| Internal Attacker| An internal attacker could extract Kubernetes secrets or otherwise access the end user’s workflow infrastructure or the workflow storage that houses workflow infrastructure artifacts|
| External Attacker | An external attacker may try to leverage API calls to look for vulnerabilities within the system. Appropriate auditing and logging procedures should be implemented to ensure that administrators can follow an audit trail to understand and mitigate attempted attacks.|
| External Attacker|An external attacker may be a developer of dependencies used by Argo Workflows or user repositories. The attacker may execute a supply chain attack that gains control of Argo infrastructure or may target the end user’s workflow infrastructure.|

### Predisposing Conditions

A list of potential vulnerabilities and configurations of the project that could
potentially be exploited or used correctly to result in an increased likelihood of
attack success. Include any trust relationships with other projects that pose a risk
of compromise for this project (i.e. compromise of the LDAP results in loss of access
control integrity for the project)

#### Argo CD

* Dex - Argo CD ships with a Dex instance by default. If Dex is compromised, a user might achieve a higher level of privileges in Argo CD.
* Using Argo CD to modify its own security configuration - Argo CD's security configuration resources (AppProjects, RBAC configuration, etc.) are Kubernetes resources. Since Argo CD has the ability to modify Kubernetes resources, it may be abused to dismantle its own security controls. Operators must carefully restrict Argo CD's RBAC and AppProjects to prevent inappropriate management of security-sensitive resources.
* Using the Kubernetes API to modify Argo CD - Argo CD's security configration (AppProjects, RBAC configuration, etc.) are Kubernetes resources. A user with insufficiently-restricted Kubernetes API access may be able to escalate privileges. Operators must consider the Kubernetes API as a path by which attackers may target Argo CD.

#### Argo Rollouts

#### Argo Workflows

#### Argo Events

### Expected Attacker Capabilities

A description of likely capabilities that the attacker has in these scenarios
should be described. Both assumptions about the strength and limitations of attackers
should be described (e.g. we assume that an attacker may be able to exploit
implementation errors in some set of the servers to take control of them. However,
we assume the attacker cannot break AES or SHA256).

### Attack Risks and Effects

A rough estimation of the risk posed by different attacks, and potential negative
consequences (e.g. the master Flibble server only communicates with Flibble servers
using a minimalistic API that is formally verified and written in Rust).

### Security Degradation

A discussion about the resulting security when various attacks are launched. Note,
that no system is secure in all scenarios, hence it is expected that this will include
areas where attacks compromise all meaningful security. (e.g., If an attacker is
able to compromise the “main” Flibble server, they may read, write, or delete any
content stored on any system). This should be stated in terms that are accessible to
a reader that does not fully understand the system. Hence, "a compromised main Flibble
key lets and attacker push and pull widgets" is less useful than saying " compromised
main Flibble key lets an attacker execute arbitrary code on client machines using the
Flibble server".

### Compensating Mechanisms

Additional architectural decisions, configuration settings, options, etc. designed to
reduce overall attack vector and success (minimize impact). Particular detail should
be paid to mechanisms that contain an attack (separation of privilege) and the
techniques used to recover from a successful attack. It is important to have clear
documentation that explains what types of security incidents are likely to occur and what
means should be undertaken to securely recover. I.e., in the case of a Flibble server
compromise, a threshold of the offline Flibble keys must be used in order to sign new
Flibble metadata to revoke the older server key. This new metadata should be
distributed to clients using the Flibble widget create operation as soon as is feasible
as in the interim clients will tryst the compromised server, enabling an attacker to
serve them outdated widgets that are known to be defective.

## Threat Model

Below is an example threat model table for key attack area (these will be unique to the
project and likely come from the security functions and features section).

### Identity Theft

|Victim Components | Server | Agent | Container on node | Container separate node |
|--|--|--|--|--|
| Victim Server | N/A | Score .11 : Mitigated, server has... | Score .11 : Mitigated,
node has... | Score .11 : Mitigated, node has... |
| Victim Agent | Score 57.5 None, significant issue... | Score. 11 : Mitigated, server
has... | Score .11 : Mitigated, node has... | Score .11 : Mitigated, node has... |

### Compromise

Use previous table outline

### Denial of Service

Use previous table outline

## Secure Development Practices

Development Pipeline:
* CI is powered by Github Actions.
* CI includes e2e tests powered by k3s.
* Following tools are used to perform code static analysis: sonarcloud, golangci-lint, snyk, tslint.
* Each pull request requires approval from at least one approver. (PR authors cannot approve own PRs).
* Contributors are required to sign off each contributed commit (add --signoff flag to git commit command).

Communication Channels:
* Internal. Internal communication is happening in CNCF slack in #argo-contributors channel.
* Inbound. User feedback and support is happening in CNCF slack using following channels #argo-cd and #argo-cd-feedback.
* Outbound. We are using twitter, medium blog and dedicated slack channel to broadcast important announcements: https://twitter.com/argoproj, https://blog.argoproj.io/, #argo-announcements.

Ecosystem.
* Hundreds of organizations are using Argo CD in production: argo-cd/USERS.md.
* Several cloud-native open-source projects integrate with Argo CD: Backstage, Tekton
* Gitlab Kubernetes Agent is built on top of Argo CD component (GitOps Engine): https://docs.gitlab.com/ee/user/clusters/agent/.
* There are several commercial products that integrate with Argo CD: Openshift GitOps, Codefresh GitOps.

Ecosystem.
* Self-reported reference organizations using Argo Workflows are listed here:: argo-workflows/USERS.md
* Several cloud-native open-source projects integrates with Argo Workflows: Kubeflow, Metaflow,

## Security Issue Resolution

Responsible Disclosures Process. The vulnerabilities disclosure process is described here: https://github.com/argoproj/argo-cd/security/policy#reporting-a-vulnerability:
We maintain a public list of contacts that should be used to report a vulnerability.
We ask you for responsible disclosure and for giving us appropriate time to react, analyze and develop a fix to mitigate the found security vulnerability.
Incident Response.
Once vulnerability is fixed we will publish security advisories using the GitHub SA feature to keep our community well informed.
We credit the reporter for their findings unless the reporter prefers to stay anonymous.

### Closed security issues and vulnerabilities

Known Issues Over Time. The list of previously reported vulnerabilities is available via following links:
* https://github.com/argoproj/argo-cd/security/advisories?state=published.

## Hands-on review

The hands-review is a lightweight review of the project's internal security
as well as the current recommendation configuration, deployment, and interaction
with regard to security. Hands-on reviews are subject to security reviewer
availability and expertise. They are not intended to serve as an audit or
formal assessment and are no gurantee of the actual security of the project.

**[Project] did/did not receive a hands-review from TAG-Security.**

*If a hands-on review was performed, the below format should be used for
reporting details*

| | |
| -- | -- |
| Date of review | mmddyyyy-mmddyyyy |
| Hands-on reviewers | name, github handle |

| Finding Number | Finding name | Finding Notes | Reviewer |
| -- | -- | -- | -- |
| | | |

### Hands-on review result

General comments and summary of the hands-on review with any recommendations worth noting. If nothing found use the below example:

> TAG-Security's hands-on review did not reveal any significant or notable security findings for [project]. This outcome does not indicate that none exist, rather that none were discovered.

## Roadmap

* Project Next Steps. Link to your general roadmap, if available, then list
prioritized next steps that may have an impact on the risk profile of your
project, including anything that was identified as part of this review.
* CNCF Requests.

What is missing is continuity, along the lines of a (yearly) recurring security refresher audit.

## Appendix

### Reported and fixed CVEs:
[Argo CD](https://github.com/argoproj/argo-cd/security/advisories?state=published)

Argo Rollouts - None

[Argo Workflows](https://github.com/argoproj/argo-workflows/security/advisories?state=published)

[Argo Events](https://github.com/argoproj/argo-events/security/advisories?state=published)

### Case Studies.
* Provide context for reviewers by detailing 2-3 scenarios of real-world use cases.
* Related Projects / Vendors. Reflect on times prospective users have asked
about the differences between your project and projectX. Reviewers will have
the same questions