Recherche

Bonjour,
que recherchez-vous ?

Fermer le volet de recherche
E-commerce
Ouvrir le menu Fermer le menu
Français Anglais
  1. Accueil
  2. Newsletter Juin 2016
  3. Nouveautés de CodeSonar 4.2 : gestion d’accès, MISRA et sécurité

Nouveautés de CodeSonar 4.2 : gestion d’accès, MISRA et sécurité

< Retour à la newsletter
Nouveautés de CodeSonar 4.2 : gestion d’accès, MISRA et sécurité
Dans cette nouvelle version de son outil CodeSonar de détection de bugs, d’erreurs « RUNTIME » et de vulnérabilité logicielles, GrammaTech met la priorité sur l’amélioration des détections de violation en regard des standards de règles de codage MISRA, ainsi qu’à la mise en place d’une gestion d’accès et de rôle dans l’interface de visualisation des résultats.

En effet, de nombreux clients souhaitaient restreindre l’affichage des résultats d’analyse d’un projet par CodeSonar à l’équipe en charge de ce projet, à un chef de projet ou à un responsable de division, et donc éviter que ceux-ci soient accessibles à l’extérieur de ce cercle restreint de personnes…

Différents niveaux de priorités peuvent être donnés, que ce soit à un seul compte, à un groupe de comptes, ou à l’ensemble des utilisateurs. De plus, les droits peuvent être définis pour tous les projets, un arbre de projets, ou même un seul projet.
CodeSonar
Les clefs à droite permettent d’accéder à la fenêtre de gestion des accès (ci-dessous). Ceux-ci peuvent être modifiés pour un projet donné ou pour un « project tree » (contenant d’autres « project tree » et/ou des projets).
CodeSonar
Après avoir créé un nouveau « rôle », on peut lui attribuer des accès par projet ou groupes de projets.
De plus, CodeSonar 4.2 ajoute le standard de règles de codage MISRA C++:2008, et améliore le support du MISRA C:2012, grâce à l’ajout de 11 nouvelles détections. La pertinence des avertissements est encore améliorée, grâce à l’élimination de faux positifs et de faux négatifs, grâce à une meilleure compatibilité avec le C++14 et le C++/CX.

 Enfin, honneur est donné à la sécurité dans cette nouvelle version. Puisque CodeSonar est de plus en plus massivement utilisé pour détecter des vulnérabilités de sécurité (en détectant des erreurs « RUNTIME » ou des tainted data), il est normal que son interface soit elle-aussi renforcée ! Désormais, CodeSonar peut être entièrement utilisé en HTTPS, et utilise la version 1.0.2e de OpenSSL. Une liste complète de ces améliorations est disponible ici (voir ci-dessous).


Afin de vous présenter plus en détails cette nouvelle version, ISIT organise un webinar d’une heure le jeudi 16 juin de 11h à 12h. N’hésitez pas à vous inscrire en cliquant ici !

Vous êtes client CodeSonar sous maintenance, et vous souhaitez obtenir cette nouvelle version ? Contactez support.qualite@isit.fr !

Vous êtes client CodeSonar, vous n’êtes plus sous maintenance, et vous souhaitez connaitre les modalités d’accès à cette nouvelle version ? N’hésitez pas à contacter contact@isit.fr pour plus d’informations !
Liste complète des nouvelles fonctionnalités de GrammaTech CodeSonar 4.2:

  • Upgraded C/C++ parser: Better compatibility with C++14 and C++/CX
  • A variety of compiler model improvements and new compiler models
  • Warnings in system headers of C++ translation units are now discarded by default
  • Role Based Access Control (RBAC) on hub 
-Specific flavor is level 2a as described in http://csrc.nist.gov/rbac/sandhu-ferraiolo-kuhn-00.pdf
-Each hub user is associated with a set of roles
-Each role is associated with a set of permissions against resources such as projects
-Analyses and launch daemons now authenticate as hub users and require permissions to operate
-The default configuration/permissions behave very much like past releases: Everything is accessible to anyone who accesses the hub
-Users who do not adjust the configuration should not see much change in behavior
-Users who want a secure style configuration should start by visiting the security dashboard. Go to the "User Administration" tab of Administrator's "Settings" page and click "Security Dashboard."
-Hubs can now have multiple administrator users.
-Administrator users can now perform normal user activities such as viewing warnings with appropriate permissions and a working license
-The stop-gap access control mechanism (based on filters) introduced in CodeSonar 4.1 has been removed
  • Many security enhancements 
-Upgraded to OpenSSL 1.0.2g
-Communication between the analysis and hub can use HTTPS
-HTTP can be disabled entirely
-TLS certificate validation more thorough
-Generated certificates are more restrictive and have higher strength
If upgrading an existing HTTPS hub, it is recommended that you regenerate your certificates if they are self-signed certificates generated by the hub
-Database no longer uses "trust" authentication
-Communication between the database and hub can use TLS
Database authentication is certificate-based when using TLS
-Communication between analysis master and workers can now use TLS with 2-way authentication
-Password hashing now done using PBKDF2 with 100k iterations (about 1 second)
Passwords that were last changed before upgrading are grandfathered in to older hashing schemes until they are reset. For maximum security, reset all passwords after upgrading.
-Eliminated notion of a default Administrator password
The user is now prompted for password when a new hub is created
-Lockout period on too many authentication attempts
-Configurable password policy
-Session cookie adjustments
Checked on every request instead of every connection. May be important in the presence of (reverse) proxies.
Marked HTTPS-only on HTTPS hubs
By default, they expire if the browser closes
Marked samesite in anticipation of https://tools.ietf.org/html/draft-west-first-party-cookies-06
-Some defenses against clickjacking
-CSRF protections added
--Advised certain browsers to not do content-type sniffing, which can cause XSS issues if the browser guesses incorrectl
-Support for certificate-based authentication (tls client auth) from analysis clients, launch daemons, and web browsers
-File-system permissions are more restrictive
-Only users allowed to see the "Hub Log" can see stack traces if the hub has an error
-Sign in failure messages contain less information
  • Project Tree structure on hub 
-Facilitates organization of projects into a file-system-like structure
-Useful for organizing and administering large numbers of projects
  • Launch Daemon Group structure on hub 
-Facilitates organization of launch daemons into a file-system-like structure
-Useful for organizing and administering large numbers of launch daemons
-Can be used to limit the nodes of the analysis cloud that get used during a distributed analysis
  • New launchd key concept can facilitate identification of otherwise indistinguishable launch daemons. Can be useful when: 
-Multiple computers connected to the hub have the same name
-Multiple chroot environments are in play
  • New "Unterminated C String" warning class
  • Multiple new MISRA warning classes 
FILE* Dereference
Implicit Function Declaration
Invalid Preprocessor Directive
Macro Definition of Reserved Name
Macro Parameter Not Parenthesized
Macro Undefinition of Reserved Name
Modified Parameter
Static Array Parameter
Trigraph
Use of offsetof
Write to Read Only File
  • Eliminated some false positives and false negatives
  • Java API plugins can now specify JVM flags such as -Xmx2g using JAVA_PLUGIN_JVM_FLAGS
  • Some performance improvements for taint analysis
  • Windows GUI has a prompt that provides a choice about whether to "-clean" or do an incremental analysis
  • "File left in an inconsistent state" errors can generally automatically be recovered from by performing a non-incremental analysis, unless the issue is with parser files
  • Configuration options for disabling parse logging to the hub. Can speed up parsing under some circumstances (but log.txt must be inspected locally)