Ja tens fmt i validate caçant errors bàsics. Però aquests comandaments comproven que el codi sigui correcte, no que sigui segur. Un codi perfectament vàlid pot crear una infraestructura perillosa: un bucket S3 obert al món, una base de dades sense xifrar, un Security Group amb SSH exposat. Per detectar això existeix l’anàlisi de seguretat estàtic, amb eines com Checkov i tfsec.

validate (subcapítol 21.1) et diria que aquest codi està «bé»:

Sintàcticament és correcte. Però estàs creant un bucket amb dades confidencials obert a internet (recorda el perill del subcapítol 5.4). validate no detecta això, perquè no és un error de codi: és un error de seguretat. Necessites alguna cosa que conegui les bones pràctiques i t’avisi.

L’anàlisi estàtic examina el teu codi sense executar-lo (sense crear res a AWS) i el compara amb una base de regles de seguretat i bones pràctiques. Si troba una configuració perillosa, t’avisa assenyalant exactament què està malament i per què.

Analogia: és com un inspector de seguretat que revisa els plànols d’un edifici abans de construir-lo. No espera que l’edifici estigui fet per descobrir que falta una sortida d’emergència: ho detecta al plànol i t’obliga a corregir-ho abans. L’anàlisi estàtic revisa els «plànols» (el teu codi) i caça els problemes de seguretat abans de desplegar.

Hi ha diverses eines per això; les dues més conegudes en el món Terraform són:

Checkov (de l’empresa Prisma/Bridgecrew) és una eina molt popular i completa. Porta centenars de regles predefinides que comproven bones pràctiques de seguretat i compliment a AWS (i altres núvols). Detecta coses com buckets públics, recursos sense xifrar, ports oberts perillosos, manca de logs, etc.

tfsec és una altra eina molt utilitzada, centrada específicament en Terraform i enfocada en seguretat. És ràpida i fàcil d’integrar. (Cal saber que tfsec s’ha anat integrant amb Trivy, una altra eina del mateix àmbit; l’ecosistema evoluciona, però la idea és la mateixa.)

Totes dues fan una feina semblant: analitzen el teu codi i et llisten els problemes de seguretat trobats. Molts equips en fan servir una o altra (o totes dues).

Aquestes eines cacen justament els errors de seguretat que hem anat esmentant al llarg del llibre:

És com tenir un expert en seguretat revisant cada canvi, que mai es cansa ni es distreu, aplicant consistentment centenars de regles que una persona no podria recordar totes.

Igual que fmt i validate (subcapítol 21.1), aquestes eines s’executen en CI, automàticament, en cada Pull Request:

Així, cap canvi insegur pot arribar a producció sense que algú l’aprovi conscientment. Si un desenvolupador, sense voler, escriu un bucket públic, el CI ho detecta i bloqueja el PR. Això és «shift left»: detectar els problemes de seguretat el més aviat possible (al codi), no quan ja són a producció i un atacant els troba abans que tu.

Exemple del món real: un desenvolupador, amb presses, configura una base de dades sense xifrar per a una prova i, sense adonar-se’n, aquell codi acaba en un PR cap a producció. El CI executa Checkov, que detecta «base de dades RDS sense xifrat en repòs» i bloqueja el PR amb un missatge clar. El desenvolupador afegeix el xifrat, torna a pujar, i ara sí passa. L’error de seguretat mai va arribar a producció, i tot de forma automàtica.

A vegades aquestes eines marquen alguna cosa que, en el teu cas concret, és intencionat i acceptable (per exemple, un bucket que ha de ser públic perquè serveix una web estàtica, subcapítol 5.5). Per a aquests casos, pots excloure regles concretes de forma justificada (amb anotacions al codi o a la configuració de l’eina). Però fes-ho conscientment i documentant-ho, no per silenciar avisos molestos sense pensar: cada excepció ha de tenir una raó clara.

• fmt i validate comproven que el codi sigui correcte, però no que sigui segur: un codi vàlid pot crear infraestructura perillosa (buckets públics, BD sense xifrar, SSH obert).
• L’anàlisi estàtic de seguretat examina el teu codi sense executar-lo i el compara amb centenars de regles de bones pràctiques, avisant de les configuracions perilloses. Com un inspector que revisa els plànols abans de construir.
• Les eines principals són Checkov (molt completa, multi-núvol) i tfsec (centrada en Terraform, ara lligada a Trivy). Fan una feina similar.
• S’integren en CI per bloquejar automàticament els canvis insegurs en cada PR: és el principi «shift left» (caçar els problemes tan aviat com sigui possible).
• Gestiona els falsos positius excloent regles concretes de forma justificada i documentada, no silenciant avisos a la lleugera.

En el següent subcapítol farem el salt a les proves més completes: els tests d’integració amb Terratest, que creen infraestructura real i verifiquen que funciona.