Vendre des logiciels au gouvernement américain ? Connaître d'abord l'attestation de sécurité

Vendre des logiciels au gouvernement américain ? Connaître d'abord l'attestation de sécurité

Vendre des logiciels au gouvernement américain ? Connaître d'abord l'attestation de sécurité PlatoBlockchain Data Intelligence. Recherche verticale. Aï.

Au cours des derniers mois, le gouvernement américain a introduit plusieurs nouvelles exigences concernant les organisations qui vendent des logiciels aux agences gouvernementales. Parce que ces nouvelles exigences sont complexes, de nombreux dirigeants ne savent pas encore comment leur organisation sera impactée. Dans cet article, je vais partager certains des concepts les plus importants que vous devrez comprendre afin de protéger vos activités gouvernementales et de rester en conformité.

Nouvelles exigences de sécurité logicielle : qu'est-ce qui a changé ?

Au cours des dernières années, des incidents de sécurité très médiatisés comme ceux qui ont affecté SolarWinds et le package open source log4j ont augmenté l'attention du gouvernement sur la sécurité des logiciels. Commençant par Décret exécutif 14028 de la Maison Blanche sur l'amélioration de la cybersécurité du pays en mai 2021, une série d'actions au cours des deux dernières années ont conduit à un ensemble d'exigences claires qui ont un impact sur tout fournisseur de logiciels gouvernemental.

À l'avenir, toute organisation vendant des logiciels au gouvernement américain devra attester qu'elle est conforme aux pratiques de développement de logiciels sécurisés décrites par le gouvernement dans le Cadre de développement logiciel sécurisé NIST.

L'une des choses les plus importantes à comprendre est que les organisations ne doivent pas simplement attester qu'elles suivent elles-mêmes ces pratiques pour le code logiciel qu'elles écrivent, mais également que les composants open source qu'elles intègrent dans leurs applications suivent également ces pratiques.

Début juin, le gouvernement a réaffirmé ces exigences en Note de service CAMO M-23-16 (PDF) et fixez des délais de mise en conformité qui approchent à grands pas - susceptibles d'arriver au quatrième trimestre de cette année (pour les logiciels critiques) et au premier trimestre de l'année prochaine (pour tous les autres logiciels).

Cela signifie qu'au cours des prochains mois, les organisations s'efforceront de comprendre ces nouvelles exigences d'attestation et de déterminer comment leur organisation s'y conformera, à la fois pour le code qu'elles écrivent elles-mêmes et pour les composants open source qu'elles intègrent dans leurs produits logiciels.

Selon M-23-16, la sanction du non-respect est sévère :

« L'agence [fédérale] doit cesser d'utiliser le logiciel si l'agence trouve la documentation du producteur du logiciel insatisfaisante ou si l'agence n'est pas en mesure de confirmer que le producteur a identifié les pratiques dont il ne peut attester… »

Cas particulièrement difficile de l'Open Source

Alors que de nombreuses organisations approfondissent les exigences d'attestation, elles découvrent que la conformité, en particulier dans des délais serrés, peut s'avérer difficile. Le NIST SSDF est un cadre complexe pour la sécurité, et il faudra du temps aux organisations non seulement pour s'assurer qu'elles se conforment à ces pratiques, mais aussi pour documenter leurs pratiques en détail.

Mais ce qui est encore plus décourageant, c'est que le gouvernement demande aux fournisseurs d'attester les pratiques de sécurité de l'ensemble de leur produit logiciel, qui comprend les composants open source de ce logiciel. Aujourd'hui, les logiciels modernes sont souvent constitués en grande partie de composants open source qui ont été bricolés, ainsi que de certains logiciels personnalisés. Dans nos recherches, nous avons constaté que plus de 90% des applications contiennent des composants open source, et dans de nombreux cas l'open source représente plus de 70% de la base de code.

Votre organisation peut attester de ses propres pratiques de sécurité, mais comment pouvez-vous attester exactement des pratiques de sécurité suivies par les mainteneurs open source qui écrivent et maintiennent le code open source que vous utilisez dans vos applications ?

C'est un énorme défi, et les organisations se tournent vers les mainteneurs open source pour plus d'informations sur leurs pratiques de sécurité. Malheureusement, beaucoup de ces mainteneurs open source sont des bénévoles non rémunérés, qui travaillent sur l'open source comme passe-temps les nuits et les week-ends. Donc, leur demander de faire le travail supplémentaire pour valider que leurs pratiques de sécurité correspondent aux normes élevées établies par le NIST SSDF n'est pas pratique.

Une façon pour les organisations d'éviter ce défi est de ne pas utiliser l'open source dans leurs applications. Et bien que cela semble être une solution simple à première vue, c'est aussi une alternative de plus en plus non viable, car l'open source est devenue à bien des égards la plate-forme de développement moderne de facto.

Une meilleure façon de résoudre ce problème est de s'assurer que les mainteneurs des paquets sur lesquels vous comptez sont payés pour effectuer cet important travail de sécurité.

Cela peut nécessiter que vous fassiez des recherches supplémentaires pour vous assurer que les composants open source que vous utilisez ont des mainteneurs derrière eux qui sont payés - soit par des entreprises bienfaitrices, par des fondations ou par des efforts commerciaux - pour valider que leurs packages répondent à ces normes de sécurité importantes. Ou vous pouvez même contacter vous-même les mainteneurs et devenir un sponsor corporatif de leur travail. Lors de la conception de votre approche, gardez à l'esprit que la plupart des applications modernes non triviales ont des milliers de dépendances open source distinctes, chacune créée et maintenue par une personne ou une équipe différente, de sorte que l'effort manuel pour faire évoluer cette approche est considérable.

Une avancée difficile mais nécessaire

Ces exigences peuvent être pénibles à respecter, mais dans le contexte de vulnérabilités de sécurité croissantes qui nuisent massivement aux secteurs public et privé, elles constituent un pas en avant nécessaire. Le gouvernement américain est le plus gros acheteur de biens et de services au monde, et c'est aussi vrai pour l'informatique que pour d'autres domaines. En utilisant son pouvoir d'achat pour imposer des améliorations à la norme de sécurité globale des logiciels, le gouvernement aide à assurer un avenir plus sûr et plus sécuritaire.

Horodatage:

Plus de Lecture sombre