Pour s’assurer que les fournisseurs de logiciels respectent les techniques de développement sécurisées, le gouvernement américain les oblige à remplir un formulaire spécial auprès de l’Office of Management and Budget.
Les exigences pour travailler avec le gouvernement fédéral américain s’enrichit d’une autre contrainte pour les éditeurs de logiciel. Ils doivent en effet remplir un formulaire d’attestation de sécurité. Ce dernier a été annoncé le 11 mars par l’Agence pour la cybersécurité et la sécurité des infrastructures (CISA) du ministère de la sécurité intérieure, qui l’a élaboré en collaboration avec l’Office of Management and Budget (OMB). Le document identifie les exigences minimales en matière de développement de logiciels sécurisés qu’un producteur de logiciels doit respecter et attester. Les solutions doivent être attestées si elles ont été développées après le 14 septembre 2022. Celles conçues avant cette date doivent renseignées toute modification par des changements de version majeurs. Une déclaration est également requise si le producteur apporte des modifications constantes au code.
Les personnes souhaitant obtenir une attestation doivent prouver que le logiciel a été développé et construit dans des environnements sécurisés. Plusieurs méthodes sont retenues telles que l’application de l’authentification multifactorielle et de l’accès conditionnel dans les environnements de développement et la création de logiciels, de manière à minimiser les risques de sécurité.
Les logiciels d’agences gouvernementales et open source exemptés
A noter que les logiciels développés par les agences fédérales ne nécessitent pas d’auto-attestation. Il en va de même pour les logiciels open source obtenus gratuitement et directement par une agence fédérale, les composants open source et propriétaires de tiers incorporés dans le logiciel, ou les logiciels obtenus gratuitement et mis à la disposition du public. Le référentiel du CISA pour la soumission de formulaires en ligne devrait être disponible à la fin de ce mois de mars, ce qui laisse (un peu) le temps aux éditeurs concernés le temps nécessaire pour comprendre le contenu et les exigences du formulaire.
Avec la protection push, GitHub empêche les utilisateurs de pousser des secrets vers un dépôt. Une fonction d’exception est toutefois proposée.
Github a commencé à déployer la protection push pour tous ses utilisateurs. De quoi s’agit-il ? C’est une fonction d’analyse des secrets qui donne aux utilisateurs la possibilité de les supprimer des commits. Les développeurs peuvent vérifier leur statut et opter pour cette option dans les paramètres de sécurité et d’analyse du code. L’analyse des secrets de GitHub protège plus de 200 types de token et de modèles provenant de plus de 180 fournisseurs de services. Les développeurs peuvent toutefois contourner un blocage même si la protection push est activée.
L’analyse des secrets peut également rechercher des modèles personnalisés dans les messages push. Elle est toujours activée par défaut, mais peut être désactivée dans les paramètres de sécurité de l’utilisateur. GitHub recommande de laisser la protection push activée et de faire des exceptions en fonction des besoins.
La filiale de Microsoft a déclaré qu’au cours des huit premières semaines de l’année 2024, il a détecté plus d’un million de fuites de secrets sur des dépôts publics. Les organisations qui bénéficient du plan Enterprise peuvent ajouter Advanced Security pour empêcher les fuites de secrets dans les dépôts privés.
Les méthodes d’accès à la mémoire de la classe sun.misc.Unsafe vieille de 20 ans dans Java pour effectuer des opérations de bas niveau seront prochainement supprimées. Leurs remplaçants java.lang.invoke dans JDK 9 et java.lang.foreign dans JDK 22 sont à privilégier.
Les méthodes d’accès à la mémoire de la classe sun.misc.Unsafe de Java seraient dépréciées pour être supprimées dans une prochaine version de la plateforme, dans le cadre d’une proposition d’amélioration du JDK (JEP) préparée par la communauté OpenJDK. Sur les 87 méthodes de la classe, 79 seraient supprimées. Ces méthodes non prises en charge ont des remplaçants suppportés depuis le JDK 9, pour l’accès à la mémoire on-heap, et le JDK 22, pour l’accès à la mémoire off-heap, selon la proposition. Les développeurs de bibliothèques sont fortement encouragés à migrer de sun.misc.Unsafe vers ces alternatives. La proposition vise notamment à préparer la suppression de ces méthodes d’accès à la mémoire dans une prochaine version de Java et à aider les développeurs à savoir quand leurs applications s’appuient sur ces méthodes. A noter qu’elle ne vise pas à supprimer entièrement la classe sun.misc.Unsafe, car un petit nombre de ses méthodes ne sont pas utilisées pour l’accès à la mémoire et resteront non dépréciées.
le document ne cite pas de version spécifique de Java qui rendrait ces méthodes obsolètes. La prochaine itération de Java standard, JDK 22, prévue pour mars, a déjà gelé ses fonctionnalités. Mais le JDK 23, qui devrait être publié en septembre, pourrait être une cible possible. Dans le passé, le code non sécurisé était considéré comme nécessaire à la programmation de bas niveau. La classe sun.misc.Unsafe a été introduite en 2002 pour permettre aux classes Java du JDK d’effectuer des opérations de bas niveau. Ses méthodes d’accès à la mémoire, comme le nom de la classe l’indique, ne sont pas sûres et peuvent entraîner un comportement indéfini, c’est pourquoi elles n’ont pas été exposées en tant qu’API standard. Elles ont été introduites en partant du principe qu’elles étaient exclusivement réservées au JDK, que les appelants au sein du JDK effectueraient des contrôles de sécurité exhaustifs avant de les utiliser et que des API standard sûres pour cette fonctionnalité seraient ajoutées à la plateforme Java, selon la proposition.
Un risque avéré de défaillance et de plantage
Mais comme, il n’existait en 2002 aucun moyen d’empêcher sun.misc.Unsafe d’être utilisé en dehors du JDK, ses méthodes d’accès à la mémoire sont devenues un couteau suisse pour les développeurs de bibliothèques qui souhaitaient disposer de plus de puissance et de performances que celle fournie les API standard. Malheureusement, toutes les bibliothèques n’effectuent pas de contrôles de sécurité avant d’appeler ces méthodes, ce qui présente un risque de défaillances et de plantages dans les applications. Au cours des dernières années, deux API standard ont été introduites pour remplacer les méthodes d’accès à la mémoire dans sun.misc.Unsafe. Il s’agit de java.lang.invoke du JDK 9 et de java.lang.foreign du JDK 22.
GitHub va commencer à sélectionner des comptes pour l’inscription à l’authentification à deux facteurs la semaine prochaine. Une procédure généralisée d’ici la fin de l’année.
Suite à un engagement pris l’année dernière, Github commencera le 13 mars à mettre en place progressivement les exigences d’authentification à deux facteurs (2FA) pour les développeurs contribuant au code du site de dépôt de code populaire. Tous les développeurs devront s’y conformer d’ici la fin de l’année. Les petits comptes devront s’inscrire à 2FA à partir de la semaine prochaine, GitHub commençant la phase de sélection pour l’inscription, a annoncé la société le 9 mars. Les personnes choisies seront informées par e-mail et verront une bannière sur GitHub.com leur demandant de s’inscrire. Les utilisateurs auront 45 jours pour configurer 2FA sur leurs comptes.
En exigeant ce renforcement d’authentification, GitHub tente de sécuriser le développement de logiciels en améliorant la sécurité des comptes. Ceux-ci sont fréquemment ciblés pour l’ingénierie sociale et la prise de contrôle de compte, a déclaré GitHub. Les utilisateurs peuvent choisir entre des méthodes 2FA telles que TOTP (Time-based One-Time Password), SMS (Short Message Service), clés de sécurité ou GitHub Mobile. La filiale de Microsoft conseille d’utiliser des clés de sécurité et des TOTP dans la mesure du possible, le SMS n’offrant pas le même niveau de protection et n’est d’ailleurs plus recommandé par le NIST 800-63B, a précisé la société.
TOTP, SMS et bientôt Passkeys supportés
GitHub a noté que les utilisateurs peuvent avoir à la fois une application d’authentification (TOTP) et un numéro SMS. Les utilisateurs verront une invite après 28 jours leur demandant d’activer le 2FA et de confirmer leurs paramètres. L’invite aidera à éviter le verrouillage du compte en raison d’applications d’authentification mal configurées. Les utilisateurs peuvent dissocier leur adresse e-mail du compte GitHub à deux facteurs s’ils ne parviennent pas à se connecter ou à le récupérer. De plus, la technologie Passkeys, qui remplace les mots de passe, est testée en interne. GitHub pense que cette technologie combinera la facilité d’utilisation avec une authentification forte et résistante au phishing.