adnv 1.5.1

CLI that tracks, checks and auto-updates infrastructure dependency versions across Terraform, Helm, Docker, Git and npm
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72

# Security Considerations

## Trust model

adnv interacts with external systems (registries, git hosts, APIs). Understanding the trust boundaries helps assess risk.

```mermaid
graph TD
    subgraph "Trusted"
        A[Local .tf / Chart.yaml files]
        B[adnv.yml config file]
    end
    
    subgraph "Semi-trusted"
        C[Private registries<br/>GitLab, GitHub]
    end
    
    subgraph "Untrusted"
        D[Public registries<br/>Docker Hub, npm]
        E[Archive downloads]
    end
    
    B --> C
    B --> D
    B --> E
    A --> |scanned by| F[adnv]
    F --> C
    F --> D
```

## Credential management

Credentials for notification backends (Mattermost, Matrix, SMTP) are stored in the YAML config file. Protect this file accordingly:

- Restrict file permissions (`chmod 600 adnv.yml`)
- Use CI/CD secret variables instead of hardcoded values
- Consider using environment variable expansion where supported

The GitHub token is read from the `ADNV_GITHUB_TOKEN` environment variable, which is the recommended approach. There is no GitLab token: every GitLab client is unauthenticated, so private GitLab projects and registries are not reachable.

## Network security

- Every HTTP client is built by `util::http`, which enforces HTTPS and caps redirects at 3
- Response bodies are capped, as is the decompressed size of a downloaded archive
- Certificate verification uses the system CA store for `git2` and the `gitlab` crate, and the bundled webpki roots for everything built on rustls — including SMTP, so a mail server behind a private CA needs that root added explicitly
- SMTP uses implicit TLS by default; `tls: false` downgrades to opportunistic STARTTLS and warns

## File system operations

The `run` command performs file system operations based on config:

- **import**: Downloads and extracts archives to temporary directories
- **output**: Copies processed files to the specified path, replacing existing content
- **update**: Modifies `.tf` and `Chart.yaml` files in-place

Ensure workflow configs come from trusted sources, as they control file system writes.

## Template rendering

Tera templates are rendered in two contexts:
1. **Workflow templates**: Variables can reference environment variables via `$` prefix
2. **Notification templates**: Access to version data context

Tera does not support arbitrary code execution, but template variables can expose environment values. Audit `variables` sections in shared configs.

## Recommendations

1. **Protect config files** containing credentials
2. **Use environment variables** for secrets rather than config values
3. **Review workflow configs** before running untrusted ones
4. **Pin source references** to specific tags/commits rather than branches
5. **Restrict CI/CD permissions** for the adnv service account