DevOps Conf 2024 - Roma - 10 mag 2024 https://devopsconf.dotnetdev.it Gli strumenti che usiamo per lo sviluppo e il rilascio sono essenziali per controllare i processi in uso e garantire che soddisfino requisiti aziendali, legali, e regolamentari. In questa sessione illustrerò come passare da norme (policies) astratte a implementationi su piattaforme come Azure DevOps o GitHub delle stesse così da poter prevenire prima e verificare poi il corretto svolgimento delle operazioni. E diventare amici del direttore Rischi e Audit.

2. Implementatori (engineer, sviluppatori, DevOps, SRE)
Teorici (Architetti, Principal)
Pianificatori (Project Manager, Manager, Principal)
A quale categoria appartenete?

3. I nostri problemi
● 1500 Licenze Visual Studio
● 100 Teams
● 1350 Applicazioni
● 10 TB in Azure DevOps Databases
● 4000 Git repositories
● 5000 Azure DevOps Pipelines
● 1200 Octopus Deploy Projects
● 1300 Octopus Deploy Tentacles
● Diecine di milioni di righe di codice
● Escluso il mainframe
● Migrazione a Services: 6 mesi, 50 script per 3500 righe
● HIPPA, CCPA, GDPR-UK
● 7 anni di conservazione
giuliovdev@hotmail.com
@giulio_vian

4. Definizione
● IT governance (ITG) is defined as the processes that ensure the effective and efficient use of IT in
enabling an organization to achieve its goals. IT demand governance (ITDG—what IT should work on)
[…omiss…]. IT supply-side governance (ITSG—how IT should do what it does) is concerned with
ensuring that the IT organization operates in an effective, efficient and compliant fashion, and it is
primarily a CIO responsibility.
— Gartner Information Technology Glossary
● Sicurezza
○ ISO 27001 (Information Security)
○ NIS2 (Network and Information Security Directive)
○ DORA (Digital Operational Resilience Act)
● Privacy
○ GDPR (General Data Protection Regulation)
○ CCPA (California Consumer Privacy Act)
○ HIPAA (Health Insurance Portability and Accountability Act)
● Garanzie
○ PCI DSS (Payment Card Industry Data Security Standard)
○ Basilea II & III
○ SOX (Sarbanes–Oxley Act)

5. Evitare
incagliarsi

6. Condotta (Pipeline)

7. Principi
● Rintracciabilità
○ Non ripudiabilità
● Sicurezza
● Separazione delle responsabilità
○ Separation of Duties
● Visibilità
○ semplicità di utilizzo
Foto: Filippo Poli

8. Regole, regole

9. Limitare Actions / Tasks
● AzDO Extensions
● GH Action Sources
● AzDO Decorators 💣

10. Addomesticare
● Repo templates [GH]
● extends templates [AzDO]
● Workflow starter templates [GH]
● Step templates [AzDO]
● Composite Actions [GH]
● Pipeline Decorators [AzDO] 💣

11. Uniformare i nomi per ciascuna
categoria di oggetti
Primo passo verso la tracciabilità
Come implementarla in GitHub
Una policy
semplice

12. Esempio di Actions Workflow
name: Check Repo Names
on:
workflow_dispatch:
jobs:
check-repo-names:
runs-on: ubuntu-latest
steps:
- name: Search for new non-compliant repositories
run: |
$auditResponse = curl --silent --header "Authorization: Bearer ${env:MY_TOKEN}" --header "Accept:
application/vnd.github+json" --header "X-GitHub-Api-Version: 2022-11-28" --request GET --url
"https://api.github.com/${env:ENTERPRISE_ORGANIZATION_FILTER}/audit-
log?phrase=operation:create+action:repo+created:>=${cutoverDate}" | ConvertFrom-Json
$violations = $auditResponse | where { $_.action -eq 'repo.create' } | where { $_.repo -notmatch
$env:VALID_REPONAME_REGEX } | select external_identity_username,org,repo,created_at
foreach ($v in $violations) {
...
$adaptiveCardBody = Invoke-EpsTemplate -Template $env:MSTEAMS_ADAPTIVECARD_TEMPLATE -binding $bindings
$msteamsReponse = Invoke-RestMethod -Uri $env:WEBHOOKURL -Method Post -Body $adaptiveCardBody -ContentType
'application/json'
}
shell: pwsh
env:
MY_TOKEN: ${{ secrets.TOKEN_WITH_AUDIT_LOG_PERMISSION }}
WEBHOOKURL: ${{ secrets.WEBHOOKURL }}
VALID_REPONAME_REGEX: ${{ vars.VALID_REPONAME_REGEX }}
MSTEAMS_ADAPTIVECARD_TEMPLATE: ${{ vars.MSTEAMS_ADAPTIVECARD_TEMPLATE }}
ENTERPRISE_ORGANIZATION_FILTER: ${{ vars.ENTERPRISE_ORGANIZATION_FILTER }}

13. Esempio di Actions Workflow
$auditResponse = curl --silent --header "Authorization:
Bearer ${env:MY_TOKEN}" --header "Accept:
application/vnd.github+json" --header "X-GitHub-Api-
Version: 2022-11-28" --request GET --url
"https://api.github.com/${env:ENTERPRISE_ORGANIZATION_FILTER
}/audit-
log?phrase=operation:create+action:repo+created:>=${cutoverD
ate}" | ConvertFrom-Json
$violations = $auditResponse | where { $_.action -eq
'repo.create' } | where { $_.repo -notmatch
$env:VALID_REPONAME_REGEX } | select
external_identity_username,org,repo,created_at

14. Esempio di notifica
Si lascia al lettore il facile
compito di inviare una mail con
allegato all’indirizzo aziendale,
in quanto di semplice soluzione

15. Quale toolchain fu usata
● Una SBOM è impraticabile
● DYI
● Per Hosted Agents/Runners
○ ImageOS ubuntu22 / win22
○ ImageVersion 20240407.1.0
○ https://github.com/actions/runner-images/releases
Foto: Dave & Margie Hill Kleerup

16. Confidenza
↑ CERTO
firma crittografica storicizzata
con chiavi multiple
↑ FIDUCIA
registrazioni alterabili da un
amministratore
↓ DEBOLE
registrazioni facilmente alterabili
da chiunque abbia accesso
↓ NESSUNA

17. Audit Logs
● Finestra di 90gg
● Streaming
○ Splunk
○ Azure Events
○ Azure Monitor [AzDO]
○ AWS S3 / Az Blob [GH]
○ DataDog [GH]

18. Policies tipiche per SDLC
● No a vulnerabilità critiche o di grado elevato
● 100% dei test eseguiti con successo
● No a segnalazioni di qualità del codice di grado elevato
● Esame di sicurezza SAST / SCA / DAST non antecedente i tre giorni al rilascio
● Test di performance entro un margine del 20% dall’obiettivo
● Codice rivisto da una persona diversa dall’autore
● Separazione delle responsabilità
○ Approvazione al rilascio da persona diversa dall’autore
○ Separation of Duties

19. Policies “esterne” al SDLC
● Architetturali
○ Applicazioni esposte ad Internet devono usare XYZ per l’autenticazione
● Configurazione
○ La scadenza dei certificati SSL non può essere superiore all’anno

20. Violazioni permesse
● Situazioni d’emergenza dove si permette una temporanea inosservanza delle regole
● Per ogni policy deve essere possible registrare la violazione
○ Chi l’ha autorizzata, quando, perché

21. In sintesi
Ogni regola (policy) ha la funzione di limitare i rischi
Difficile farlo senza intaccare la velocità
e la semplicità operativa
Cardini nella prevenzione e nel riconoscimento

23. Riferimenti
https://www.gartner.com/en/information-technology/glossary/it-governance
https://billbensing.com/
https://itrevolution.com/product/devops-automated-governance-reference-architecture/
https://www.infoq.com/articles/enterprise-github-actions/
https://docs.github.com/en/enterprise-cloud@latest/admin/policies/enforcing-policies-for-your-
enterprise/enforcing-policies-for-github-actions-in-your-enterprise
https://learn.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/add-incoming-
webhook?tabs=newteams%2Cdotnet
https://www.powershellgallery.com/packages/EPS/1.0.0
https://learn.microsoft.com/en-us/azure/devops/pipelines/process/templates
https://learn.microsoft.com/en-us/azure/devops/extend/develop/add-pipeline-decorator
https://dev.to/n3wt0n/github-composite-actions-vs-reusable-workflows-updated-2023-bl8
https://docs.github.com/en/actions/creating-actions/creating-a-composite-action
https://docs.github.com/en/enterprise-cloud@latest/actions/using-workflows/reusing-workflows
https://docs.github.com/en/enterprise-cloud@latest/repositories/creating-and-managing-repositories/creating-a-
template-repository
https://docs.github.com/en/enterprise-cloud@latest/actions/managing-workflow-runs/reviewing-deployments
https://www.youtube.com/watch?v=dNl3qpJZ12w

24. Riferimenti
https://github.blog/2023-04-05-building-organization-wide-governance-and-re-use-for-ci-cd-and-automation-with-
github-actions/
https://docs.github.com/en/enterprise-cloud@latest/admin/policies/enforcing-policies-for-your-enterprise
https://www.youtube.com/watch?v=dNl3qpJZ12w (Scalable governance policies across your GitHub
organization)

25. Shift-left approach (GitHub)
Lessons Learned from Enterprise Usage of GitHub
Actions - InfoQ