![\"Le](\"https:\/\/ukan.cloud\/wp-content\/uploads\/2018\/03\/Langage-java.png\")
<\/p>\n<\/p>\n
DevSecOps signifie d\u00e9veloppement, s\u00e9curit\u00e9 et op\u00e9rations. Il s’agit d’une approche de la culture, de l’automatisation et de la conception des plateformes qui int\u00e8gre la s\u00e9curit\u00e9 comme une responsabilit\u00e9 partag\u00e9e tout au long du cycle de vie informatique.<\/p>\n
Malgr\u00e9 la croissance de l’adoption de DevSecOps au cours des derni\u00e8res ann\u00e9es, il existe des lacunes importantes dans la s\u00e9curisation des d\u00e9ploiements cloud. Datadog a publi\u00e9 son rapport State of DevSecOps 2024, d\u00e9voilant des informations cl\u00e9s sur l’adoption des pratiques DevSecOps et les d\u00e9fis auxquels les organisations sont confront\u00e9es pour s\u00e9curiser les d\u00e9ploiements dans le cloud.<\/p>\n
Datadog pr\u00e9sente son rapport en d\u00e9clarant :<\/strong><\/p>\n Nous avons analys\u00e9 des dizaines de milliers d’applications et d’images de conteneurs, ainsi que des milliers d’environnements cloud<\/b>, afin d’\u00e9valuer le niveau de s\u00e9curit\u00e9 des applications actuelles et l’adoption des meilleures pratiques qui sont au c\u0153ur de DevSecOps – infrastructure en tant que code, d\u00e9ploiements cloud automatis\u00e9s, pratiques de d\u00e9veloppement d’applications s\u00e9curis\u00e9es et utilisation d’informations d’identification \u00e0 dur\u00e9e de vie courte dans les pipelines CI\/CD.<\/p>\n Nos conclusions d\u00e9montrent que les pratiques DevOps modernes vont de pair avec des mesures de s\u00e9curit\u00e9 solides – en fait, la s\u00e9curit\u00e9 contribue \u00e0 l’excellence op\u00e9rationnelle. Notre \u00e9tude montre \u00e9galement que si la s\u00e9curit\u00e9 commence par la visibilit\u00e9, la s\u00e9curisation des applications n’est r\u00e9aliste que lorsque les praticiens b\u00e9n\u00e9ficient d’un contexte et d’une hi\u00e9rarchisation suffisants pour se concentrer sur ce qui compte, sans se perdre dans le bruit.<\/p><\/div>\n FAIT 1 : Les services Java sont les plus touch\u00e9s par les vuln\u00e9rabilit\u00e9s des tiers<\/span><\/b><\/p>\n En analysant le niveau de s\u00e9curit\u00e9 d’une s\u00e9rie d’applications \u00e9crites dans diff\u00e9rents langages de programmation, ils ont constat\u00e9 que les services Java sont les plus touch\u00e9s par les vuln\u00e9rabilit\u00e9s des tiers :\u00a090 % des services Java sont vuln\u00e9rables \u00e0 une ou plusieurs vuln\u00e9rabilit\u00e9s critiques ou de haute s\u00e9v\u00e9rit\u00e9<\/b>\u00a0introduites par une biblioth\u00e8que tierce, contre une moyenne de 47 % pour les autres technologies.<\/p>\n Les services Java sont \u00e9galement plus susceptibles d’\u00eatre vuln\u00e9rables \u00e0 des exploits r\u00e9els dont l’utilisation par les attaquants est document\u00e9e. L’Agence am\u00e9ricaine pour la cybers\u00e9curit\u00e9 et la s\u00e9curit\u00e9 des infrastructures (CISA) tient une liste permanente des vuln\u00e9rabilit\u00e9s exploit\u00e9es dans la nature par des acteurs mena\u00e7ants, le catalogue KEV (Known Exploited Vulnerabilities). Cette liste, mise \u00e0 jour en permanence, est un bon moyen d’identifier les vuln\u00e9rabilit\u00e9s les plus importantes que les attaquants exploitent activement pour compromettre les syst\u00e8mes. \u00c0 partir des vuln\u00e9rabilit\u00e9s figurant dans cette liste, ils ont constat\u00e9 que les services Java sont surrepr\u00e9sent\u00e9s :\u00a055 % des services Java<\/b>\u00a0sont touch\u00e9s,\u00a0contre 7 %<\/b>\u00a0de ceux qui sont con\u00e7us \u00e0 l’aide d’autres langages.<\/p>\n Cette surrepr\u00e9sentation se v\u00e9rifie m\u00eame lorsqu’on se concentre sur des cat\u00e9gories sp\u00e9cifiques de vuln\u00e9rabilit\u00e9s – par exemple, 23 % des services Java sont vuln\u00e9rables \u00e0 l’ex\u00e9cution de code \u00e0 distance (RCE), ce qui affecte 42 % des organisations. La pr\u00e9valence des vuln\u00e9rabilit\u00e9s ayant un impact dans les biblioth\u00e8ques Java les plus r\u00e9pandues – notamment Tomcat, Spring Framework, Apache Struts, Log4j et ActiveMQ – peut expliquer en partie ces chiffres \u00e9lev\u00e9s. Les vuln\u00e9rabilit\u00e9s les plus courantes sont les suivantes<\/p>\n L’hypoth\u00e8se est renforc\u00e9e lorsque l’on examine l’origine de ces vuln\u00e9rabilit\u00e9s. En Java,\u00a063 % des vuln\u00e9rabilit\u00e9s importantes et critiques proviennent de d\u00e9pendances indirectes<\/b>, c’est-\u00e0-dire de biblioth\u00e8ques tierces qui ont \u00e9t\u00e9 indirectement int\u00e9gr\u00e9es \u00e0 l’application. Ces vuln\u00e9rabilit\u00e9s sont g\u00e9n\u00e9ralement plus difficiles \u00e0 identifier, car les biblioth\u00e8ques suppl\u00e9mentaires dans lesquelles elles apparaissent sont souvent introduites dans une application sans qu’on le sache.<\/p>\n Il est donc essentiel de prendre en compte l’arbre de d\u00e9pendance complet, et pas seulement les d\u00e9pendances directes, lors de l’analyse des vuln\u00e9rabilit\u00e9s d’une application. Il est \u00e9galement essentiel de savoir si toute nouvelle d\u00e9pendance ajout\u00e9e \u00e0 une application est bien entretenue et si elle met fr\u00e9quemment \u00e0 jour ses propres d\u00e9pendances. Des cadres tels que l’OpenSSF Scorecard sont utiles pour \u00e9valuer rapidement la sant\u00e9 des biblioth\u00e8ques open source.<\/p>\n Jeff McJunkin, Fondateur de Rogue Valley Information Security et instructeur SANS :<\/b><\/p>\n La surface d’attaque de votre organisation ne se limite pas au code public que vous avez \u00e9crit, elle englobe \u00e9galement les d\u00e9pendances de vos applications, qu’elles soient directes ou indirectes. Comment suivez-vous les vuln\u00e9rabilit\u00e9s dans ces d\u00e9pendances ? En outre, \u00eates-vous en mesure d’alerter rapidement en cas de compromission ? Comment limiter les d\u00e9g\u00e2ts ? Si la plupart des vuln\u00e9rabilit\u00e9s ne m\u00e9ritent pas d’\u00eatre consid\u00e9r\u00e9es comme prioritaires, celles qui pr\u00e9sentent un fort potentiel d’exploitation se trouvent souvent dans des applications surprivil\u00e9gi\u00e9es avec des informations d’identification \u00e0 longue dur\u00e9e de vie, ce qui accro\u00eet leur gravit\u00e9 potentielle.<\/p><\/div>\n FAIT 2 : Les tentatives d’attaque des scanners de s\u00e9curit\u00e9 automatis\u00e9s sont pour la plupart des bruits qui ne peuvent pas \u00eatre pris en compte.<\/span><\/b><\/p>\n Ils ont analys\u00e9 un grand nombre de tentatives d’exploitation contre des applications dans diff\u00e9rentes langues. Ils ont constat\u00e9 que les attaques provenant de scanners de s\u00e9curit\u00e9 automatis\u00e9s repr\u00e9sentent de loin le plus grand nombre de tentatives d’exploitation. Ces scanners sont g\u00e9n\u00e9ralement des outils open source que les attaquants tentent d’utiliser \u00e0 grande \u00e9chelle, en scannant l’ensemble de l’internet pour identifier les syst\u00e8mes vuln\u00e9rables. Nuclei, ZGrab et SQLmap sont des exemples populaires de ces outils.<\/p>\n Ils ont constat\u00e9 que\u00a0la grande majorit\u00e9 des attaques effectu\u00e9es par les scanners de s\u00e9curit\u00e9 automatis\u00e9s sont inoffensives et ne g\u00e9n\u00e8rent que du bruit<\/b>\u00a0pour les d\u00e9fenseurs. Sur les dizaines de millions de requ\u00eates malveillantes que nous avons identifi\u00e9es en provenance de ces scanners, seulement 0,0065 % ont r\u00e9ussi \u00e0 d\u00e9clencher une vuln\u00e9rabilit\u00e9. Cela montre qu’il est essentiel de disposer d’un cadre solide pour la hi\u00e9rarchisation des alertes afin de permettre aux d\u00e9fenseurs de surveiller efficacement les journaux bruts des serveurs web ou les alertes du pare-feu d’application web (WAF) du p\u00e9rim\u00e8tre. L’int\u00e9gration de renseignements sur les menaces et du contexte d’ex\u00e9cution des applications dans les d\u00e9tections de s\u00e9curit\u00e9 peut aider les organisations \u00e0 filtrer les menaces les plus critiques.<\/p>\n FAIT 3 : Seule une petite partie des vuln\u00e9rabilit\u00e9s identifi\u00e9es m\u00e9rite d’\u00eatre trait\u00e9e en priorit\u00e9<\/span><\/b><\/p>\n En 2023, plus de 4 000 vuln\u00e9rabilit\u00e9s importantes et 1 000 vuln\u00e9rabilit\u00e9s critiques ont \u00e9t\u00e9 identifi\u00e9es et inventori\u00e9es dans le cadre du projet CVE (Common Vulnerabilities and Exposures). Les recherches de Datadog ont permis de constater qu’un service moyen est vuln\u00e9rable \u00e0 19 de ces vuln\u00e9rabilit\u00e9s. Toutefois, selon des recherches universitaires ant\u00e9rieures, seuls 5 % environ des vuln\u00e9rabilit\u00e9s sont exploit\u00e9es par des attaquants dans la nature.<\/p>\n Compte tenu de ces chiffres, il est facile de comprendre pourquoi les praticiens sont submerg\u00e9s par la quantit\u00e9 de vuln\u00e9rabilit\u00e9s auxquelles ils sont confront\u00e9s, et pourquoi ils ont besoin de cadres de priorisation pour les aider \u00e0 se concentrer sur ce qui est important. Ils ont analys\u00e9 un grand nombre de vuln\u00e9rabilit\u00e9s et calcul\u00e9 un \u00ab score ajust\u00e9 \u00bb bas\u00e9 sur plusieurs facteurs suppl\u00e9mentaires afin de d\u00e9terminer la probabilit\u00e9 et l’impact d’une exploitation r\u00e9ussie :<\/p>\n Ils ont \u00e9galement pris en compte le score du syst\u00e8me de pr\u00e9diction des exploits (Exploit Prediction Scoring System – EPSS), en accordant plus de poids aux vuln\u00e9rabilit\u00e9s qui ont obtenu un score plus \u00e9lev\u00e9 pour cette mesure. Ils ont appliqu\u00e9 cette m\u00e9thodologie \u00e0 toutes les vuln\u00e9rabilit\u00e9s afin d’\u00e9valuer combien d’entre elles resteraient critiques sur la base de leur score ajust\u00e9. Ils ont constat\u00e9 qu’apr\u00e8s l’application de notre notation ajust\u00e9e,\u00a063 % des organisations<\/b>\u00a0qui avaient des vuln\u00e9rabilit\u00e9s avec une gravit\u00e9 CVE critique\u00a0n’ont plus de vuln\u00e9rabilit\u00e9s critiques<\/b>. Par ailleurs,\u00a030 % des organisations<\/b>\u00a0ont vu leur nombre de vuln\u00e9rabilit\u00e9s critiques\u00a0r\u00e9duit de moiti\u00e9 ou plus<\/b>.<\/p>\n Pour d\u00e9terminer les vuln\u00e9rabilit\u00e9s \u00e0 traiter en priorit\u00e9, les organisations doivent adopter un cadre qui leur permette d’\u00e9valuer de mani\u00e8re coh\u00e9rente la gravit\u00e9 du probl\u00e8me. En r\u00e8gle g\u00e9n\u00e9rale, une vuln\u00e9rabilit\u00e9 est plus grave si<\/p>\n Bien que d’autres vuln\u00e9rabilit\u00e9s puissent encore pr\u00e9senter un risque, elles ne devraient \u00eatre trait\u00e9es qu’apr\u00e8s les probl\u00e8mes qui r\u00e9pondent \u00e0 ces trois crit\u00e8res.<\/p><\/div>\n En mati\u00e8re de d\u00e9veloppement de logiciels et de s\u00e9curit\u00e9, le moins est souvent le mieux. C’est particuli\u00e8rement vrai dans le contexte des d\u00e9pendances tierces, telles que les images de base des conteneurs. Il existe g\u00e9n\u00e9ralement plusieurs options pour choisir une image de base, notamment :<\/p>\n En analysant des milliers d’images de conteneurs, ils ont constat\u00e9 que plus une image de conteneur est petite, moins elle est susceptible de pr\u00e9senter de vuln\u00e9rabilit\u00e9s, probablement parce qu’elle contient moins de biblioth\u00e8ques tierces. En moyenne, les images de conteneurs de moins de 100 Mo pr\u00e9sentent\u00a04,4 vuln\u00e9rabilit\u00e9s \u00e9lev\u00e9es ou critiques, contre 42,2<\/b>\u00a0pour les images de 250 \u00e0 500 Mo, et\u00a0pr\u00e8s de 80<\/b>\u00a0pour les images de taille sup\u00e9rieure.<\/p>\n Cela d\u00e9montre que dans les environnements conteneuris\u00e9s, l’utilisation d’images l\u00e9g\u00e8res est une pratique essentielle pour minimiser la surface d’attaque, car elle permet de r\u00e9duire le nombre de biblioth\u00e8ques tierces et de paquets du syst\u00e8me d’exploitation dont d\u00e9pend une application. En outre, les images l\u00e9g\u00e8res permettent de r\u00e9duire les besoins en stockage et le trafic r\u00e9seau, ainsi que d’acc\u00e9l\u00e9rer les d\u00e9ploiements. Enfin, les images de conteneurs l\u00e9gers permettent de minimiser les outils \u00e0 la disposition d’un attaquant, y compris les utilitaires syst\u00e8me tels que curl ou wget, ce qui rend l’exploitation de nombreux types de vuln\u00e9rabilit\u00e9s plus difficile.<\/p>\n Jay Beale, PDG de la soci\u00e9t\u00e9 de conseil InGuardians :<\/b><\/p>\n Lorsque je joue le r\u00f4le de l’acteur de la menace dans des environnements de conteneurs comme Kubernetes, les images de conteneurs construites sur distroless rendent ma journ\u00e9e plus difficile.<\/p><\/div>\n FAIT 5 : L’adoption de l’infrastructure en tant que code est \u00e9lev\u00e9e, mais varie d’un fournisseur de cloud \u00e0 l’autre<\/span><\/b><\/p>\n Le concept d’infrastructure en tant que code (IaC) a \u00e9t\u00e9 introduit dans les ann\u00e9es 1990 avec des projets tels que CFEngine, Puppet et Chef. Apr\u00e8s que l’informatique en nuage ait gagn\u00e9 en popularit\u00e9, l’IaC est rapidement devenue une norme de facto pour l’approvisionnement des environnements en nuage. L’IaC pr\u00e9sente des avantages consid\u00e9rables pour les op\u00e9rations, notamment le contr\u00f4le des versions, la tra\u00e7abilit\u00e9 et la reproductibilit\u00e9 entre les environnements. Sa nature d\u00e9clarative aide \u00e9galement les \u00e9quipes DevOps \u00e0 comprendre l’\u00e9tat souhait\u00e9, plut\u00f4t que de lire d’interminables scripts bash d\u00e9crivant comment y parvenir.<\/p>\n L’IaC est \u00e9galement consid\u00e9r\u00e9e comme une pratique essentielle pour la s\u00e9curisation des environnements de production en nuage, car elle permet de garantir que :<\/p>\n Ils ont constat\u00e9 que sur AWS,\u00a0plus de 71 % des organisations utilisent l’IaC<\/b>\u00a0par le biais d’au moins une technologie IaC populaire telle que Terraform, CloudFormation ou Pulumi. Ce chiffre est inf\u00e9rieur dans Google Cloud,\u00a0avec 55 %<\/b>.<\/p>\n Il est \u00e0 noter qu’ils n’ont pas pu faire de rapport sur Azure, car les journaux d’activit\u00e9 Azure ne consignent pas les agents utilisateurs HTTP.<\/p>\n Sur AWS et Google Cloud, Terraform est la technologie la plus populaire, juste avant les outils IaC sp\u00e9cifiques au cloud, \u00e0 savoir CloudFormation et Google Deployment Manager.<\/p>\n FAIT 6 : Les d\u00e9ploiements manuels dans le nuage sont encore tr\u00e8s r\u00e9pandus<\/span><\/b><\/p>\n Les humains, heureusement, ne sont pas des machines, ce qui signifie qu’on est condamn\u00e9s \u00e0 faire des erreurs. Un \u00e9l\u00e9ment majeur du contr\u00f4le de la qualit\u00e9, et par extension de la s\u00e9curit\u00e9, est l’automatisation des t\u00e2ches r\u00e9p\u00e9titives qui peuvent \u00eatre retir\u00e9es des mains de l’homme.<\/p>\n Dans les environnements de production en nuage, un pipeline CI\/CD est g\u00e9n\u00e9ralement charg\u00e9 de d\u00e9ployer les modifications apport\u00e9es \u00e0 l’infrastructure et aux applications. L’automatisation qui a lieu dans ce pipeline peut \u00eatre r\u00e9alis\u00e9e avec des outils IaC ou par des scripts utilisant des outils sp\u00e9cifiques aux fournisseurs de cloud.<\/p>\n L’automatisation garantit que les ing\u00e9nieurs n’ont pas besoin d’un acc\u00e8s privil\u00e9gi\u00e9 permanent \u00e0 l’environnement de production, et que les d\u00e9ploiements sont correctement suivis et examin\u00e9s par les pairs. L’oppos\u00e9 de cette meilleure pratique, \u00e0 savoir l’ex\u00e9cution manuelle d’actions \u00e0 partir de la console cloud, est souvent d\u00e9sign\u00e9 sous le nom d’op\u00e9rations par clics ou ClickOps.<\/p>\n En analysant les journaux CloudTrail, ils ont identifi\u00e9 qu’au moins\u00a038 % des organisations dans AWS avaient utilis\u00e9 ClickOps dans tous leurs comptes AWS<\/b>\u00a0dans une fen\u00eatre de 14 jours pr\u00e9c\u00e9dant la r\u00e9daction de cette \u00e9tude. Selon la d\u00e9finition de Datadog, cela signifie que ces organisations ont d\u00e9ploy\u00e9 des charges de travail ou pris des mesures sensibles manuellement via la console de gestion AWS –\u00a0y compris dans leurs environnements de production<\/b>\u00a0– au cours de cette p\u00e9riode.<\/p>\n FAIT 7 : L’utilisation d’identifiants \u00e0 dur\u00e9e de vie courte dans les pipelines CI\/CD est encore trop faible.<\/span><\/b><\/p>\n Dans les environnements cloud, les fuites d’informations d’identification \u00e0 longue dur\u00e9e de vie sont l’une des causes les plus courantes des violations de donn\u00e9es. Les pipelines CI\/CD augmentent cette surface d’attaque car ils disposent g\u00e9n\u00e9ralement d’autorisations privil\u00e9gi\u00e9es et leurs informations d’identification peuvent fuir par le biais d’une journalisation excessive, de d\u00e9pendances logicielles compromises ou d’artefacts de construction, comme dans le cas de la violation de Codecov. L’utilisation d’identifiants \u00e0 courte dur\u00e9e de vie pour les pipelines CI\/CD est donc l’un des aspects les plus critiques de la s\u00e9curisation d’un environnement en nuage.<\/p>\n Cependant, ils ont constat\u00e9 qu’un nombre important d’organisations continuent \u00e0 utiliser des informations d’identification \u00e0 long terme dans leurs environnements AWS, m\u00eame dans les cas o\u00f9 des informations d’identification \u00e0 court terme seraient \u00e0 la fois plus pratiques et plus s\u00fbres. Parmi les organisations utilisant les actions GitHub, soit plus de 31 % des organisations fonctionnant sur AWS, nous avons constat\u00e9 que\u00a0seulement 37 % utilisent exclusivement une authentification \u00ab sans cl\u00e9 \u00bb<\/b>\u00a0bas\u00e9e sur des informations d’identification \u00e0 court terme et OpenID Connect (OIDC). Par ailleurs,\u00a063 % ont utilis\u00e9 au moins une fois des utilisateurs IAM<\/b>\u00a0(une forme d’authentification \u00e0 long terme) pour authentifier les pipelines GitHub Actions, tandis que\u00a042 % ont utilis\u00e9 exclusivement des utilisateurs IAM<\/b>.<\/p>\n L’utilisation de l’authentification sans cl\u00e9 dans les pipelines CI\/CD est plus facile \u00e0 mettre en place et plus s\u00fbre. Une fois de plus, cela montre que les bonnes pratiques op\u00e9rationnelles tendent \u00e9galement \u00e0 conduire \u00e0 de meilleurs r\u00e9sultats en mati\u00e8re de s\u00e9curit\u00e9.<\/p>\n \u00c0 propos de Datadog<\/b><\/p>\n La plateforme SaaS de Datadog int\u00e8gre et automatise la surveillance de l’infrastructure, la surveillance de la performance des applications, la gestion des journaux, la surveillance de l’utilisateur r\u00e9el et de nombreuses autres capacit\u00e9s afin de fournir une observabilit\u00e9 et une s\u00e9curit\u00e9 unifi\u00e9es et en temps r\u00e9el pour l’ensemble de la pile technologique de ses clients.<\/p><\/div>\n 90% des services Java en production pr\u00e9sentent un risque de vuln\u00e9rabilit\u00e9, selon le rapport DevSecOps de Datadog. Le rapport State of DevSecOps 2024 de Datadog d\u00e9taille les vuln\u00e9rabilit\u00e9s des services […]<\/p>\n","protected":false},"author":2,"featured_media":6518,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[21,200,12,189],"tags":[],"class_list":["post-6514","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-actualite","category-langage","category-logiciels","category-programmation"],"yoast_head":"\n\n\nL’envoi de code s\u00e9curis\u00e9 rapidement et \u00e0 grande \u00e9chelle est un d\u00e9fi pour toute l’industrie du logiciel, comme le montrent les informations continues sur les violations de donn\u00e9es et les vuln\u00e9rabilit\u00e9s critiques qui font la une. Pour relever ce d\u00e9fi, les organisations adoptent de plus en plus DevSecOps, une pratique dans laquelle les d\u00e9veloppeurs d’applications travaillent en \u00e9troite collaboration avec les \u00e9quipes d’exploitation et de s\u00e9curit\u00e9 tout au long du cycle de d\u00e9veloppement. DevSecOps envisage la s\u00e9curit\u00e9 des applications de mani\u00e8re globale, en reconnaissant que le code doit \u00eatre s\u00e9curis\u00e9 non seulement dans la mani\u00e8re dont il est \u00e9crit, mais aussi dans la mani\u00e8re dont il est d\u00e9ploy\u00e9 et ex\u00e9cut\u00e9 en production.<\/p>\nVoici les r\u00e9sultats de l’\u00e9tude en 7 faits :<\/div>\n\n<\/div>\n
\n
<\/div>\n
\n\n\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n
\n
<\/div>\n
\n
<\/div>\n\nFAIT 4 : Les images de conteneurs l\u00e9gers entra\u00eenent moins de vuln\u00e9rabilit\u00e9s<\/span><\/b><\/p>\n\n
<\/div>\n
\n\n\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n
<\/div>\n
<\/div>\n
<\/div>\n
<\/div>\n\n\u00ab\u00a0State of DevSecOps 2024\u00a0\u00bb (Datadog)<\/div>\n<\/div>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"