El model tradicional i els seus costos
En el model clàssic de desenvolupament de programari, la seguretat era domini d'un equip especialitzat que testejava el sistema just abans del desplegament en producció. Les vulnerabilitats trobades generaven costoses desviacions de treball — els programadors havien de tornar a tasques tancades feia temps, entendre el context de setmanes enrere i introduir canvis que afectaven altres elements ja testejats. La frustració era mútua: l'equip de seguretat era percebut com un bloqueig, els programadors com a no preparats per escriure codi segur.
La filosofia shift-left
Shift-left significa literalment desplacar les activitats de seguretat cap a l'esquerra en l'eix temporal del projecte — de la fase de proves i desplegament a la fase de disseny i codificació. Com més aviat es detecti una vulnerabilitat, més econòmic i senzill és eliminar-la. Un programador que veu una alerta de vulnerabilitat en el seu entorn de desenvolupament segons després d'escriure el codi problemàtic la corregeix immediatament, sense perdre el context i sense interrompre el flux de treball de tot l'equip.
Automatització en el pipeline CI/CD
Shift-left es materialitza integrant controls de seguretat automàtics en cada etapa del pipeline d'integració i lliurament continus. Cada commit desencadena una seqüència de verificacions de seguretat que bloqueja el pas a l'etapa següent si es detecten vulnerabilitats greus.
- SAST (anàlisi estàtica del codi) — detecta vulnerabilitats en el codi font sense executar-lo: injeccions SQL, deserialitzacions no segures, ús de funcions perilloses
- SCA (anàlisi de composició del programari) — escaneja dependències per detectar vulnerabilitats conegudes, comprova llicències, detecta biblioteques obsoletes
- Escaneig de secrets — bloqueja la confirmació accidental de contrasenyes, claus API i certificats al repositori
- DAST (anàlisi dinàmica) — testa l'aplicació en funcionament en un entorn de prova, simulant atacs a les interfícies API i web
- Proves de contenidors i infraestructura — verificació de la configuració d'imatges Docker i definicions d'infraestructura per detectar errors de seguretat
La seguretat com a codi
Les organitzacions madures tracten les polítiques de seguretat com a codi — les defineixen en fitxers de configuració emmagatzemats al repositori, sotmesos a revisió i proves. Això significa que les regles WAF, les polítiques de xarxa, les configuracions de sistemes de detecció d'anomalies i les polítiques RBAC es gestionen amb el mateix rigor que el codi de l'aplicació. Els canvis requereixen revisió, l'historial és auditable i el rollback és possible en minuts.
La cultura com a fonament
Les eines sense cultura no donen resultats. DevSecOps requereix que els programadors entenguin les conseqüències de les decisions de disseny per a la seguretat i tractin les alertes no com a obstacles, sinó com a feedback valuos. Això implica inversió en formació, disponibilitat d'experts de seguretat com a socis en el disseny (no auditors), mètriques clares i responsabilitat compartida de les vulnerabilitats. ESKOM.AI aplica el model DevSecOps en el desenvolupament dels seus propis sistemes, combinant l'automatització de proves amb una cultura de responsabilitat compartida per la seguretat en cada etapa del cicle de desenvolupament.