In this work, we conduct a systematic review of the field, gathering 290 relevant publications—at the time of writing, the largest curated dataset on the topic. We analyse our dataset along two lines: (a) quantitatively, through publication metadata, which allows us to chart publication outlets, communities, approaches, and tackled issues; (b) qualitatively, through 20 research questions used to provide an aggregated overview of the literature and to spot gaps left open. We summarise our analyses in the conclusion in the form of a call for action to address the main open challenges.Microservices is an emerging paradigm for developing distributed systems. With their widespread adoption, more and more work investigated the relation between microservices and security. Alas, the literature on this subject does not form a well-defined  Each microservice implements the business logic of a component of the application and is independently executable and deployable. Microservices interact with each other ing APIs .via technology-agnostic APIs.Over the last 6 years, microservices have become a popular topic and one of the go-to approaches for many cloud computing projects. According to Web of Science, more than 1,000 articles about microservices have been published since 2014. The year 2020 accounts for more than 400 of them, which points out that interest in the topic is still rising. Microservices are popular because they bring substantial advantages with respect to scalability in cloud environments and flexibility in the process of software development. By separating application components as independent services, software designers can specialise each component by using a dedicated technology and then integrate all such heterogeneous components Alas, the advantages of microservices come at a cost: distributed systems are hard to manage, and increasing the number of services of an application gives malicious actors a larger attack surface . SeveralThe importance of security in microservices creates the need for understanding and analysing the state of the art for securing this kind of architectures. It is particularly important to understand which problems are especially relevant for microservice systems, and how existing techniques can contribute to addressing them. However, there is still a lack of systematic investigations of studies at the intersection of security and microservice architectures.Here, we aim to fill that gap by presenting a systematic review of the state of the art of microservice security. We followed a structured approach, which led us to select and gather 290 peer-reviewed publications. At the time of this writing, this constitutes the largest curated dataset on the topic. We first perform a quantitative analysis on the metadata of the publications, for example, publication outlets and keywords. This provides insight into the communities and key research concepts that currently characterise the field. We then map each publication to a vector of 20 different markers, corresponding to 20 research questions on microservices security that we formulated based on established security techniques and the field of microservices as a whole.e.g., Intrusion Detection and Intrusion Prevention, and Agile Development and DevOps as well). Findings from our analysis include: issues with technology transfer from academia to industry on microservices security; lack of guidelines for adopting security by design in microservices; lack of appropriate threat models; lack of guidelines for addressing the attack surface given by technology heterogeneity; and security issues when migrating systems to microservices. Our data, findings, and discussions form a useful basis for orienting future developments of the field.Our research questions focused on threat models, security approaches, infrastructure, and development approach. We perform correlation analysis to show that our questions are well-posed (independence), and also to confirm that some topics correlate positively ;the identification of the main research communities on the Microservice Security field and the clustering of authors (Research Communities);a presentation of the trends of the main security attacks involving microservice architectures, both from the points of view of threat model (Threat Model) and mitigation (Security Approach (Mitigation));a report on the current infrastructural security solutions for microservices (Infrastructure) as well as the interaction between the main microservices development approaches (such as DevOps and Agile) and security (Development);a correlation analysis of the answers to our research questions in papers, which sheds light on relationships among the different aspects of microservice security (Correlation between Research Questions);a summary of the main open challenges that emerged from our study, which form a call for action for the community of researchers and practitioners working in the field of microservice security (Discussion and Future Directions).In summary, the main contributions of this work are:We start by providing a summary of related work in “Related Work”. In “Review Method” and “Research Questions” we detail the method we followed to conduct the systematic literature review and the research questions, respectively. We present our results in “Review Results” and we conclude in “Discussion and Future Directions” with a discussion on the outstanding challenges.e.g., authentication and authorisation—leaving out other subjects related to security, like threat models and development methods. Similarly to To the best of our knowledge, the published works that are closest to ours are those by Extending our view to articles that, at the time of this writing, are not available as peer-reviewed publications, we mention the work by etc. The purpose of reviewing neighbouring related work is twofold:It shows the multifaceted nature of microservice security, giving concrete evidence of the need for an investigation which is both wider and deeper, as we do in this work.It provides a general overview of the challenges and possible uncovered research topics related to security in microservices—which inspired some of the questions presented in “Review Method”.In addition to the related work discussed above, there are quite a few neighbouring surveys with respect to our work that are interesting to discuss: while these studies are not dedicated to the topic of microservice security, they explicitly mention security as an important concern for microservices in different contexts—software engineering, Internet of Things, containerisation, e.g., due to data leakages derived from fragile container-host interactions.e.g., authentication and access control) when system design permits direct access to resource-constrained devices. Reviewing the many solutions and levels at which IoT interoperability can be tackled, Also In this section, we describe and motivate the steps we followed to perform our systematic review.i.e., recursively adding to the dataset relevant publications cited by the already selected publications. The resulting dataset consists of 290 publications. We analysed these publications to collect statistical and transparent answers to our research questions, which are detailed in “Research Questions”.1https://doi.org/10.5281/zenodo.4774894.The list of the publications and their bibliography information is publicly available at Following the guidelines by 2We performed experiments with potentially more inclusive queries, such as “Microservice AND (Security OR Authorisation)”, as well. The tried queries, however, did not extend the search in any useful way since the term “Security” proved to be general enough to cover specialised aspects like authentication, authorisation, and (safe) communication.Security in microservices includes complex and heterogeneous topics, ranging from development to infrastructural concerns. In our choice of a selection query to gather an initial dataset, it was important to pick a sufficiently general query. For this reason, we adopted the query “Microservice AND Security” for our initial search, capturing all the publications containing both terms in any of their title, abstract, or body.etc., are often the preferred venues for practitioners to share ideas. However, as also pointed out in https://dl.acm.org/), 478 publications;ACM (https://ieeexplore.ieee.org/), 181 publications;IEEE explore (https://link.springer.com/), 345 publications;Springer (https://www.scopus.com/home.uri), 134 publications;Scopus (https://www.sciencedirect.com/), 358 publications;Science Direct (https://onlinelibrary.wiley.com/), 208 publications.Wiley , publications not written in English, and duplicate publications already listed in another publisher source.In the 3rd Step, we looked at the title, abstract, and conclusion of each publication. Publications that do not treat or discuss topics related to microservices and security were excluded. In this step, we also excluded publications in which the security topic was orthogonal or incidental. In this way, we excluded publications where “microservices and security” was one of the possible application scenarios, but not the main subject of the study. We also excluded cases in which the work tangentially mentioned the satisfaction of some security aspects, without detailing the design/development of the security technologies to accomplish them. For example, we excluded publications focusing on blockchain technologies where the authors incidentally mention authentication and integrity protection as inherent security properties of blockchain-based implementations.In the 4th Step, we performed an analysis of the publications, answering to the research questions (RQ) detailed in Research Questions. No publications were excluded at this step.ACM, 67 publications;IEEE explore, 59 publications;Springer, 46 publications;Scopus, 28 publications;Science Direct, 53 publications;Wiley, 15 publications.At this point, the following publications remained in the dataset :As the last (5th) step for the systematic literature review, we performed a backward snowballing process  with thei.e., until no new publications was added to the dataset.All references collected in this way underwent the triage by following the Steps 2, 3, and 4. Each referenced publication accepted for inclusion by these steps was then added to the dataset of selected publications. Snowballing was recursively performed on these newly-added publications until reaching a fixed point; 40 references in the first round, from which we selected 9 publications;22 references in the second round, from which we selected 8 publications;5 references in the third round, from which we selected 5 publications;4 references in the fourth round, where we selected 0 publications.The outcome of repeatedly applying the snowballing process led to the following results:The 4 cycles of snowballing yielded 22 additional publications that were included in the dataset to reach the final size of 290 publications.In this section, we detail the research questions that guided our systematic review.i.e., with yes-or-no answers), to favour precision and objectiveness. To define the questions and seek guidance in categorising the relevant security issues for microservices, we took inspiration from the related work presented “Related Work”, as well as from the state of the art in standards and methods, namely the NIST Special Publication 800-204 “Security Strategies for Microservice-based Application Systems”  but dichotomous (Systems” .Gs), each covering a different concern.G1: Threat Model. Questions on threat modelling and how threats are dealt with.G2: Security Approach. Questions on the security approach, e.g., whether it is preventive, adaptive, proactive, or reactive.G3: Infrastructure. Questions on the infrastructure that microservices run on.G4: Development. Questions on the development process.Our questions are collected in four macro groups ?Q3: If STRIDE aspects or equivalent are considered, does the publication propose/discuss a concrete implementation/solution (either developed by the same author or one taken from the literature)?Q4: Does the publication consider or follow another threat model rather than STRIDE without introducing a new one?Q5: Does the publication mention policies, workflows, or guidelines to handle violations?This group consists of the following questions.In particular, with question Q1 and Q3 we looked for the adoption of STRIDE, being the most popular threat model. In the remaining questions, we investigate if the publication defined some threat model—either from the literature or a newly one introduced in that publication—or at least discussed equivalent principles or guidelines without mentioning STRIDE.Many related works cite the usage of preventive measures to secure microservices  while soQ6: Does the publication mention Intrusion Detection System (IDS) functionalities?Q7: Does the publication mention Intrusion Prevention Systems (IPS) functionalities?Q8: Does the publication mention Threat Intelligence?Q9: Does the publication mention Exfiltration Leaks?Q10: Does the publication address Insider Threats?Q11: Are microservices part of the solution?Q12: Are privacy and GDPR considered?This group consists of the following questions.The NIST report by Q13: Does the publication specify how the proposed architecture is controlled or managed ?Q14: Does the publication mention Infrastructure-as-a-Service?Q15: Does the publication mention service discovery?In this group of questions, we aimed at finding information on the infrastructure configurations considered in the publication. This group consists of the following questions.Microservices are often associated with software development practices like DevOps and Agile  which, iIn this last set of questions, we aimed at checking the extent to which these practices are used also in the setting of security, for example by verifying whether specific development processes and security standards are considered.Q16: Does the publication mention DevOps, Continuous Integration, Continuous Deployment, or Continuous Delivery?Q17: Does the publication mention Agile, or how security experts are integrated from a development process point of view?Q18: Does the publication mention Domain Driven Development?Q19: Does the publication mention Model Driven Development?Q20: Does the publication mention certifications, such as ISO27000 (https://www.iso.org/isoiec-27001-information-security.html), or technological standards such as X.509 (https://tools.ietf.org/html/rfc5280)?This group consists of the following questions.etc.) and of the relation between the selected dataset and our research questions (cf. “Research Questions”). The qualitative part is aimed at providing a detailed insight on existing research patterns, gaps, and uncovered areas of the field. We close the subsection with a correlation analysis of the questions, providing a quantitative look over the relationships between them. For reference, we also report our dataset in tabular form, each entry associated with the positive answers given to our research questions.In this section, we present the outcome of the literature review. We start by presenting quantitative results from the metadata of the publications in our dataset. This is useful to map the trends over time and current shape of the field, in terms of number of contributions, type , communities, and keywords (and their relations). Then, we present qualitative results derived from the analysis of the types of contributions  the main insights that emerge from our analysis. Each insight motivates an open challenge, which we write in bold as the heading of the insight. We will use these challenges in “Discussion and Future Directions” to structure our discussion about useful future directions for research on microservice security.We start our quantitative analysis of the collected dataset by presenting in 3https://dblp.org/statistics/publicationsperyear.html.Source: As a reference to indicate the degree of growth of the field, we report in From the plot in In We now concentrate on the specific conferences and journals where the publications in our dataset have been published. In Regarding the distribution of publications over the different categories of venues, we note how the audience of journals and conferences vary. In fact, there is no predominance of security-oriented or even software engineering venues, which could have been the most likely targets. Instead, the analysed publications appear on publications addressing a broad range of topics, from networking to cloud computing, and on open journals such as IEEE Access and ACM Queue. Furthermore, there is no clear preferred venue that dominates the others, but contributors are rather scattered over many neighbouring venues.etc.). On the other hand, we notice the lack of specific venues dedicated to microservices, and least of all, dedicated to microservice security.We give a twofold interpretation to the phenomenon. On the one hand, this fact can indicate that microservice security is perceived as of cross-disciplinary interest, each contribution seeing it from the lens of its specific area . This makes it difficult for researchers and practitioners to keep up with the state of the art, as well as to find dedicated conventions where they can discuss this topic with the rest of the community interested in the area.i.e., prolific authors that, by working with different people, act as a liaison among separated groups of authors.To add more insight on the communities of the field, we also perform a network analysis to identify and explore the clusters of the most prolific authors and their research collaborations. Specifically, we are interested in analysing the networks of collaboration of “core authors”, i.e., authors with more than 2 works in the dataset—we remove all those clusters formed around just one work—i.e., where the maximum number of publications published by the most prolific author is one.To find the clusters of core authors in our dataset, we consider all the authors in the dataset and we aggregate them in clusters such that each member of a cluster has at least one contribution published with one of the members of the cluster. Since we are interested in “core authors”—A to P. For each Cluster, we report the name of the author, the number of publications (# pub.) in our dataset and their affiliation.Our analysis extracted 16 clusters from our dataset. We report in F, G, J, and L are totally localised in one country or the same University/Institute, they are relatively small (compared to the others in the Table), and include some of the most prolific authors (J and L in particular). Four other clusters follow a different trend: C, H, P and I. They are big-size clusters , they count one core author  but they are rather homogeneous, the first mainly including authors from Brasil, Finland and the fourth one from Portugal. Clusters A, B, D, K, M, N and O are the most varied. Cluster A, is the largest (22 authors) and most heterogeneous one: it includes 6 core authors from 5 different countries  and 12 co-authors from 4 countries different from those of the core authors . Cluster B includes 6 core authors over 24 members, distributed over just 5 countries . Cluster D includes 8 authors, of which 6 are core and come both from either China or US. Cluster K is another big cluster of 16 authors with include 3 core authors from US and Germany. Clusters M, N and O follow the same trend of cluster D. This means that these clusters are build around 2 core authors which represent the main affiliation provenance, respectively Holland, Germany and Switzerland, US and UK.The measure gives some interesting insights. First, clusters A, B, D, K) of co-authors linked by a few (if not one) core authors and diverse affiliations;“open” clusters  of localised collaborators with sporadic, external collaborations;“semi-open” clusters  that tend to be small but whose core authors tend to be the most prolific (L).“closed”, localised clusters  is to establish international collaborations and coordinate to foster the advancement and growth of the field.corpus. Specifically, we ignored basic words and copyright statements, and performed a full-count of the words present in the text. We considered only words occurring more than 15 times, sizing them by their relevance in terms of occurrences. The resulting graph, however, is still too large and dispersive to convey useful information: for the sake of clarity we present here a visualisation including only the top 60% most-occurring words.We conclude our quantitative analysis by providing a graphical representation of the main keywords present in the abstract of the contributions in our dataset. To conduct our analysis, we used VOSviewer by We report the visualisation of the analysis in VOSviewer automatically clustered the words in 4 areas using its modularity-based clustering algorithm, which is a variant of the cluster algorithm developed by microservice and system. The result does not surprise, since those words describe the design of the systematic selection we performed.The blue area marks the main terms of this study, grouping words like container or attack.The green area marks technical terms as e.g., the targets or reasons of the research, if it is an industrial or research-focused article. We find for instance the word Internet-of-Things, as it is mainly cited with industry and research applications rather than along with terms like container and cloud.The red area identifies application terms, tool, data , users, and they privacy. The word tool here is peculiar, as it acts as a bridge between the other areas. Also this finding is somehow expected, as the field of microservice security is marked by a fairly practical orientation towards automatisation of processes and control.The yellow area includes words that identify the subject of a study, whether it be some We can interpret the clusters as follows:In this section, we discuss trends and considerations derived from reading the selected publications and the research question detailed in “Research Questions”.In Theoretical for publications that present an approach for a specific problem without any implementation artefact.Applicative for publications that describe an implemented application possibly with its validation.Theoretical and Applicative for publications that develop a theory and provide a practical tool, framework, program, or application.Review for both literature reviews and social studies .More precisely, regarding the type of research contribution, we mapped every publication in our dataset to one of the following types:e.g., for proposals of attack models or techniques for handling security within organisations and development teams notwithstanding the possible explanations above, it is worth noting the (quantitative) distance between contributions from academia and applications available to practitioners and the industry, which is an indicator of an untapped potential for joint synergies between the two communities.Reviews constitute the 15% of works, marking the fragmented shape of the field, which is in rapid expansion and in need for studies to map its research landscape. Besides surveys, the other contributions in the field are distributed among a 52% share that introduce new theoretical results, a 20% share that contribute by pairing new theoretical proposals with implementations, and the remaining 11% describing pure applications. The fact that the main publications in the field are of theoretical nature is surprising, given the prominently applied nature of microservices. Indeed, excluding surveys, we have that for every 5 publications slightly more than 3 (64% of them) are of purely theoretical. We attribute this figure to two phenomena. The first marks the current exploratory trend of the field, which is still engaged in proposing new ideas and in evaluating and maturing them into models amenable to implementation. The second phenomenon relates to the impact that microservices have at the processes/organisational level, with works that are intrinsically theoretical because their contribution can be hardly crystallised into automated implementations, After having characterised the type of publications in the field, we proceed by exploring the results from the answer of the research questions following the 4 macro-groups presented in “Research Questions”.Technology transfer: the field of microservice security is still in the early phase of new idea proposals. There are just a few implementations of these ideas, which hinders industrial adoption.A total of 176 publications (ca. 65% of the dataset) give a positive answer to at least one question of this category. However, only 53 publications among those 120  mentioned the usage of at least one threat model to analyse or classify threats The reason for those publications to adopt a threat model vary, from publications that use the model to motivate their proposed solutions to reviews that use the model to structure their overview of the state of the art. Interestingly, in ca. 80% of those publications that mention the usage of at least one known threat model, the model is tailored to work on a specific application scenario. This is an indication of the lack of usage of a generic threat model for microservice security. We conjecture that this lack of usage of generic threat models is due to the fact that the majority of research done on microservice security comes from the software  side of the field, rather than from the side of security, which advocates for a security-by-design approach.e.g., due to the difficulty of making the model specific enough for microservices yet avoiding the infamous problem of threat explosion, where the effort required to prioritise and consider all threats starts exceeding the benefits of proposing methods to manage them A complementary explanation of that phenomenon is that there is no affirmed threat model for microservices, Regarding the possible attacks addressed in the publications, e.g., scale up peripheral microservices and hit more central and well-protected components with (distributed) overpowering attacks.A similar consideration can be made for denial-of-service attacks, where the flexible scalability of microservices allows malicious intruders to, Adoption of security-by-design: security in microservices frequently comes as an afterthought, whereas it should be one of the main concerns for their engineering.Data provenance: the quantity of spoofing, tampering, and repudiation attacks highlights the need to address the general problem of data provenance in microservices.Dedicated attack trees and threat models: while there are attacks that specifically pertain to microservices, such as those that leverage the scalability of microservice architectures to cause denial of service, there are no dedicated threat models to help developers become aware of those particular threats.In terms of solutions to security issues proposed by the publications (questions Q6–Q10), the most common approach (45 publications) is to address specific problems, such as authentication or exfiltration, rather than suggesting a general approach. Publications dealing with architectural aspects rarely address the overall picture . Again, they focus on local threats like intra-communications or authentication (question Q11). These observations suggest that there is a lack of security approaches that address applications across the full stack.As far as privacy and GDPR are involved (question Q12), surprisingly, only 9 publications consider privacy protection relevant or worthy of analysis. In particular, only one publication Global view/control: the distributed nature of microservices introduces the need for technologies that provide global yet decentralised observability and control, i.e., tools that aid in the enforcement of security policies over a whole architecture without single points of failure.React & recover techniques: while we found solutions to prevent and detect attacks, there are only a few proposals about how microservice systems could react to and recover from them.Comprehensive technological references: microservices use diverse sets of technology stacks, each characterised by peculiar exploits. To secure microservice architectures effectively, implementors need dedicated technological references to avoid known threats.Q13. The breakdown of the answers is:39% (80) describe a centralised approach;24% (49) use a decentralised approach;17% (35) resort to a hybrid approach;20% (41) do not specify which approach they use.We start the discussion by first focusing on the type of microservice infrastructure used by the various contributions. Specifically, we have 205 publication in our dataset that answer positively to question e.g., blockchains), has led to a decentralisation of control, making new decentralised or hybrid solutions emerge (in our dataset) starting from 2018. As an example, in 2015 and 2016, we find publications such as The most widely adopted turns out to be the centralised one. We conjecture two explanations behind this observation. First, the centralised approach has the merit of simplifying the definition, deployment, monitoring, and evolution of policies holding over all the components in a given architecture—traded off with scalability issues and single-point-of-failure concerns. Second, we note that, among the approaches that appeared early in the literature, many focused on converting monolithic applications into microservice applications. Clearly, having a centralised controller that manages the orchestration of microservices helps this process and is closer in spirit to the monolithic workflow. However, the advent of federated, multi-cloud solutions  as well as new distributed-consensus technologies , which is the focus of question Q14, is also a recurrent topic in our dataset, with 66 publications yielding a positive answer. IaaS include solutions that provide and manage low-level infrastructural components, like computing resources, data storage, network components, i.e., the automatic detection of services and their functionalities available in a given architecture/network. A total of 16 publications mention Service Discovery in the context of security. Mainly, they propose architectures that support reactive mechanisms for the detection of security issues. Of those, only 2 mention service registration procedures that include data for performing the preventive analysis of the composition, with the goal of statically finding and fixing possible vulnerabilities and misconfigurations: Question Q15 investigates Service Discovery, Global view/control: while there is not a definitive approach to microservice security control , there is a recognised need for applying security control policies in a consistent way across all microservices belonging in the same architecture.DevOps and Agile are recurring topics in our dataset. Based on the answer to question Q16, 76 publications used the DevOps approach, while, answering to Q17, 57 used Agile methods—of those 99 publications which represent the 40% of all publications in our dataset, 10 mention both approaches. There is a common consensus in these publications that Agile/DevOps is important in security because microservices seem to be the perfect match for this type of software development model . In partMigration is one of the main challenges faced in this context; migrating applications introduces important security concerns  that areWhen considering domain- and model-driven approaches (questions Q18 and Q19), 16 publications consider domain-driven approaches and 26 consider model-driven ones, such as i.e., curated sets of technologies, policies, concepts, safeguards, guidelines, assessments, procedures, training programmes that should be adopted to reduce security risks and mitigate attacks. The answers we gathered for this question surprised us. Indeed, security standards are a staple element of industries and organisations that want to impose and guarantee a certain level of security on their members and collaborators  as well as the lack of more and more mainstream technologies like service mesh and serverless.Regarding blockchain technologies, we found 31 publications mentioning or explicitly using blockchains. The decentralisation and independence of microservices constitute a good pairing for the usage of blockchain technologies. i.e., a dedicated infrastructure layer for facilitating service-to-service communications between microservices is just mentioned by 3 works: New approaches for microservices design and usage such as service mesh Similarly, serverless In this context, the most relevant publication is Given their increasing importance and impact in the industry and their close relation with microservices, we argue that both service mesh and serverless will attract the general attention of the research community in the near future, as well as that of security research.Comprehensive technological references: the progressive adoption of new technologies in the world of microservices  calls for dedicated investigations and reports on their impact on the security of these systems.The amount of data collected in our dataset is large enough to represent a statistically-relevant sample. In this section, we leverage this to study correlations between our research questions, by way of the answers that the publications in our dataset give to each of them. Correlations can be used to understand which of the different aspects of microservice security are most commonly in a positive correlation (paired) in the dataset, and which ones are negatively correlated .We report in We conditionally colour the cells of the Table, first, attributing colour intensity according to correlation absolute value—maximal intensity for 100% and degrading towards 0%—, second, setting a transition threshold above 30%  from green to orange, to help to spot relevant correlations. Looking at the Table, we notice the predominance of light-coloured cells. This result can be interpreted as an indication that the research questions used in this work are mostly orthogonal, and thus suited to cover the reviewed subject with almost no wasteful overlap.i.e., negative correlations over the 30% threshold in absolute value. In the following, we comment on all positive correlations above 30%.No anti-correlation was found, i.e., negative correlations over the 30% threshold in absolute value. In the following, we comment on all positive correlations above 30%.No anti-correlation was found, Q2–Q4 (32.80%) The questions relate the use of STRIDE threat model with one of its identified specific threats. This seems to be an obvious correlation since we are looking for a specific STRIDE path, or at least one of his threats.Q7–Q6 (77.49%) The questions ask if the publication mentions IPS or IDS functionalities respectively. The strong correlation indicates how IPS and IDS are strictly related. Indeed, in practice, IDS may exist without IPS, but not the opposite, because prevention mechanisms are typically built as a reaction to a detected attack;Q8–Q14 (31.15%) The questions relate Threat Intelligence functionalities with Infrastructure as a Service deployment, which can define a campaign strategy for a Threat Intelligence analysis.Q17–Q16 (57.34%) The questions relate the Agile development methodology with DevOps and Continuous Integration. As also emphasised in other studies like Q19–Q18 (40.00%) The questions relate Domain-Driven Development and Model-Driven Development. We conjecture that this correlation is present because mentions of Domain-Driven Development often mentions Model-Driven Development as an alternative approach and vice versa;Q18–Q17 (33.08%) The questions relate Domain-Driven Development and Agile methodologies, indicating a correlation, mainly because often Agile methodologies employ Domain-Driven Development.Our study is subject to limitations that can be categorised into construct validity, external validity, internal validity, and reliability following the guidelines of Construct validity “reflects to what extent the operational measures that are studied really represent what the researcher has in mind and what is investigated according to the research questions”. To mitigate a potential misinterpretation and making sure that the constructs discussed in the research questions are not interpreted differently by the researchers, we adopted various triangulation rounds using online meetings and we designed a set of binary research questions to foster objectivity in answering them.i.e., whether we may have missed any significant publication in our review. This risk cannot be completely mitigated but to minimise this risk we deliberately chose to have simple and broad keywords giving more initial hits that later were further filtered out. Moreover, we conducted a snowballing process to extend our initial dataset looking for potentially relevant publications that our query did not select.Another potential risk regards whether we were exhaustive during data collection, External validity regards the applicability of a set of results in a more general context and is not a concern for this study since we focus on the intersection of the fields of microservices and security without any attempt of generalising the findings to a broader context. We do not claim that either our qualitative or our quantitative findings should also hold for other large fields.Internal validity is of concern when causal relations are examined when there is a risk that the investigated factor is also affected by a third factor. This thread is not a concern for this study because we presented only correlations between different factors but did not examine causal relations.Reliability concerns to what extent the data collection and analysis depend on the actual researchers. This risk has been partially mitigated by selecting as many objective criteria as possible for the filtering and by requiring at least a two-people consensus in case of more subjective decisions. In particular, the retrieval of the publications was performed by using search engines. The first filtering of the results  was conducted by running a script that uses objective criteria such as counting the number of keywords present and the length of the publication. These automatically computed results were double-checked by at least one author to prevent problems due to the parsing of PDFs and to make sure that the language of the publication was English. The second filtering  performed by reading the title, abstract, and (if needed) the body of the publication, was performed in parallel by two authors. Decision conflicts were solved by discussion involving at least two authors until a consensus was reached. For the publication analysis , due to the binary nature and formulation of the questions, the 20 research questions were answered by the author assigned to the publication. To detect possible observer bias and errors, we selected a random subset of 15 papers and had a different author answer to the research questions. The calculation of the kappa index of agreement as proposed in κ = 0.99998, giving us statistical confidence over the perceived precision of questions and objectiveness of answers.https://doi.org/10.5281/zenodo.4774894, which includes both the final dataset with the answers to all the research questions and also the set of rejected publications along with the reason for exclusion.The reliability of the study is strengthened by being open and explicit about the process of data collection and analysis. For transparency, reproducibility, and reuse, we report the data used in this study at We also report in the Appendix each entry of our dataset and its answers to our research questions.In this article, we presented a systematic review of the literature regarding microservice security. To conduct our research, we followed a structured approach that allowed us to gather 290 peer-reviewed publications, which, at the time of writing, constitutes the largest curated dataset on the topic.To study our dataset, we conducted first an investigation on the metadata of the publications, which gave us some insight to map what are the publication outlets, the communities, and the key research concepts that characterise the field. Then, we performed an analysis, associating each element in our dataset to a vector of 20 different markers—presented in the form of 20 research questions.e.g., the usage of blockchain or service-mesh technologies. To provide a more comprehensive picture of the field, we described and contextualised also these additional elements. Since our dataset forms a statistically relevant vector field, we also performed a correlation study over the components of the vectors and reported the strongest correlations  and intrusion-prevention (IPS) systems in microservice deployments) along with possible explanations of the identified phenomena.Since our markers belong in four micro-groups , we used that partition to provide an overview of the literature through the lenses of each cluster. As a byproduct of our analysis on the content of each publication, we found concepts and topics that we did not include in our questions but that recur in multiple publications, In the following, we draw a summary of the main open challenges that emerged from our study, which forms a call for action for the community of researchers and practitioners working in the field of microservice security and its neighbouring areas.Data provenance: the distributed nature of microservices calls for the certification of their outputs, which other federated services receive as input and need to trust. However, there is a lack of best practices and/or standards for such a task.Technology transfer: there exists a sensible amount of research on microservices security, but transferring those results—e.g., viable methods and tools for validation and verification—to the industry is difficult and applications are almost non-existent.Security-by-design adoption: while many advocate for adopting security-by-design at all stages of a microservice lifecycle (from design to monitoring), there are no established references nor guidelines on how these principles can be reliably adopted in practice.Dedicated attack trees and threat models: threats in microservice systems can come from multiple sources, from the interaction of the layers of a chosen technology stack to how microservices interact with each other—e.g., in an exclusive network, on a federated basis, on the Web, etc. Practitioners lack dedicated attack trees and threat models to help them consider and tackle the multifaceted attack surface of microservice architectures.Comprehensive technological references: microservice development entails the use of (heterogeneous) technology stacks, whose combinations and interactions give way to exploits at different levels. These include data leakage due to host-container interactions, threats to encryption reliability due to interacting heterogeneous standards and data-format conversions, as well as surreptitious attacks through software libraries hijacking. Besides the lack of dedicated threat models, there is also a need for concrete references to secure specific technology stacks.Migration to microservices: several works provide structures and methods to migrate legacy systems to microservices architectures. However, there are no established techniques to elicit the assumptions and invariants  of the legacy system that the developers of the microservices must deal with—least of all considering how those factors impact the security aspects of the migrated architecture. An additional step in this direction would benefit from following principled security-by-design disciplines.Global view/control: the distributed nature of microservices makes it difficult to check the correct implementation of architecture-wide security policies, especially when each microservice has a dedicated security configuration. The issue is further exacerbated by the DevOps practice of having different teams deal separately with all aspects of the microservices they develop, including the implementations of their security policies. This fact highlights the need for tools that provide global overviews and guarantees on the security policies, protocols, and invariants of microservice systems.React & recover techniques: while the literature on preventive and detective measures against attacks abound, little has been done on how microservices should react to attacks and, as a consequence, recover their normal behaviour.DevSecOps: Agile and DevOps practices are widely used when developing microservices, yet there is no established reference on how these approaches should integrate security in all their aspects  and into the lifecycle of microservices.Fragmentation of outlets: researchers (and practitioners) working on microservices security do not have reference venues . This has at least two negative consequences. First, it makes it more difficult to gather the relevant work that constitutes the current state-of-the-art of their field—a need to which this study provides a partial solution, in the form of a snapshot of the current field landscape. Second, reference venues work also as gathering and exchange points for researchers to discuss current problems and new ideas, form interest groups, and concretise new contributions and projects to advance the knowledge in the field. Here, our call for action is at the community level, advocating for the establishment of a few reference, high-quality venues able to focus, inform, and orient the agenda of the field.e.g., those by NIST), white papers—constitutes a relevant body of knowledge that deserves separate studies. As future work, we intend to pursue an activity similar to what we presented in this work, but purposed to investigate the grey literature.Regarding the future steps of the line of work of this contribution, we notice that here we focused our investigation on peer-reviewed publications. However, in the general field of microservices  the grey literature—which includes non-peer-reviewed reports, working papers, government documents  Theoretical, (ii) Applicative, and (iii) Theoretical and Applicative publications and iv) Survey. For each table we have 5 columns. The first 4 columns from the left (after the column containing the reference (“Ref.”) to the publication from the publications dataset) and grouped under the column group “Group” report the 4 Research Questions Groups as defined in “Research Questions”. The value shown indicates the amount of questions of each group the publications answered. The last column labeled “Q.Num.” presents the number of questions having a positive answer.10.7717/peerj-cs.779/supp-1Supplemental Information 1Click here for additional data file.10.7717/peerj-cs.779/supp-2Supplemental Information 2Click here for additional data file.


In order to shorten construction periods, concrete is often cured using steam and is loaded at an early age. This changes the performance and even the durability of the concrete compared to concrete that has been cured under normal conditions. Thus, the pattern and the mechanism of concrete performance change under different curing conditions, and loading ages are of great significance. The development of brittleness under different curing conditions and loading ages was studied. The evaluation methods that were used to determine concrete brittleness were expounded. Steam, standard, and natural curing conditions were carried out on single-side notched concrete beams as well as on a concrete prism and cubic blocks. The compressive strength and splitting tensile strength of the concrete blocks along with the fracture performance of the concrete beams were tested after 3, 7, 28, and 90 days. The steam curing condition significantly improved the strength of concrete before 28 days had passed, and the standard curing condition improved the strength of concrete after 28 days. Based on the experimental fracture parameters, a two-parameter fracture model was applied to study the development of fracture toughness  In order to accelerate the construction progress, steam curing is often applied in order to shorten the curing time so that concrete can be loaded at early ages. However, the steam curing condition exacerbates the hydration reaction of concrete in a short period of time during the early curing stages ,2,3,4. SConcrete is recognized as a quasi-brittle material. When brittle concrete has been used in engineering infrastructure, sudden structural failures can occur. The brittleness of concrete plays a critical role in many performance indexes. Brittleness not only reflects the internal characteristics of the material but also affects the actual performance of concrete structures ,12. ConsUnder steam curing conditions, the initial strength of concrete increases; this is because as the curing temperature increases, the degree of hydration during the initial stage is intensified, resulting in the rapid accumulation of numerous hydration products, forming high initial strength ,15,16. HIn this study, the strength , fracture property , which consisted of medium sand with a size of 0.08–2 mm and a fineness of 2.6, was used; the density of the fine aggregate was 2584 kg/m3. The chemical components of the fly ash are shown in Ordinary Portland cement (OPC) was used in this research; the cement density was 1450 kg/mThree curing conditions were applied, where the group A was steam-cured, group B was standard-cured, and group C was naturally cured. The second number after the group name denoted the loading age. In the A group, the specimens were further divided into a 3-day-loading group, which was denoted by A-3, a 7-day-loading group, which was denoted by A-7, and a 28-day-loading group, which was denoted by A-28. The specimens in groups B and C were loaded on the 28th day, and the specimen groups are shown in For the steam curing, after the concrete specimens were created and had been set aside for four hours, the temperature was increased at a rate of 10 °C/h for three hours until the steam temperature reached a constant temperature of 45 °C. The concrete temperature at the core of the beam was controlled so that it did not exceed 60 °C. A constant temperature of 45 °C was maintained for 62 h, and then a controlled cooling rate was implemented at 10 °C/h for three hours. When the specimens were removed from the steam curing box, the temperature difference between the concrete core and the surface was controlled. The temperature between the surface and the environment was also controlled to be within 15 °C. For the standard curing process, the concrete specimens were placed in the standard curing room, the standard curing temperature was set to 21 °C, the humidity was set to 95%, and the curing duration was 28 days. For the natural curing condition, the specimens were covered with geotextile and were sprayed with water, and the temperature was maintained at 14.5 °C, with a curing time of 28 days.3 were used to test the strength of the concrete. Three cubic specimens were used for each group, and the total number for each test was 51. The compressive strength and the splitting tensile strength tests were performed using a universal testing machine in accordance with the GB/T 50081-2002 standard [Cubic specimens with the dimensions of 100 × 100 × 100 mm3 were used for the elastic modulus test, which was performed on a universal testing machine in accordance with the GB/T 50081-2002 standard [Prism specimens with the dimensions of 100 × 100 × 300 mm3 were used for the fracture property tests. A total number of 51 beams were used, with 3beams per group. The initial seam height ratio was 0.3, as shown in Precast notched-beam specimens with the dimensions of 100 × 100 × 515 mmThe three-point bending capacity The fracture property test was performed by a microcomputer-controlled electronic universal testing machine, crack opening displacement was tested by an electronic extensometer, and fracture strain was tested using a strain acquisition instrument. The applied pressure and the displacement of the beam were automatically recorded by the acquisition module of the testing machine. The fracture property test was repeated at the 3rd, 7th, 28th, and 90th days.The testing process consisted of loading–unloading–loading. First, a load was applied that was 95% of the maximum load, Pmax, at a rate of 0.02 mm/min. Then, it was unloaded at a rate of 30 N/s. Finally, it was reloaded to failure, as shown in The concrete crack initiation was monitored using an electrical method. When the concrete beam was loaded, the strain on both sides of the crack tip increased as the load increased. When the cracks appeared, the concrete that was under tension on both sides of the cracks shrank because of the cracks, and strain hysteresis appeared, and the strain dropped rapidly. However, at this point, the load did not reach the peak value, and the applied load continued to increase, and the strain continued to decrease. The strain hysteresis point was the crack initiation load, and the peak load was the load limit. The strain gauge distance was 30 mm, and the spacing was 10 mm. The test setup and arrangement are shown in The test results were labeled according to the following rules: The first letter represented the curing condition, with A representing steam curing, B representing standard curing, and C representing natural curing; the second number represented the loading age; and the third number denoted the age of the test. For example, A-28-90 represented the test results of the steam-cured concrete loaded at the 28th day and tested at the 90th days. Each group consisted of three beams, and P-CMOD curves were drawn, as shown in The P-CMOD curves of the concrete beams under no load, that were tested on the 28th day, that were tested under three curing conditions, are shown in The P-CMOD curves of the concrete that had been cured using the standard method were fuller compared to the steam- and naturally cured specimens, and the bearing capacity did not decrease rapidly after reaching the load limit. This phenomenon indicated that the fracture energy of the concrete under standard curing was larger and could consume more energy, resulting in reduced brittleness.The crack initiation load and the load limit of the concrete under the three curing conditions are shown in The crack initiation and load limit data for the specimens under the three curing conditions after 3, 7, 28, and 90 days showed that the steam curing condition significantly improved the early bearing capacity, which adversely affected the strength values in the later stages. Furthermore, the standard curing condition positively affected the later bearing capacity, and the effects of natural curing on the bearing capacity of the concrete during the initial and later stages were weaker than the abovementioned two curing conditions.The ratio of the crack initiation load to the load limit represented the brittleness of the concrete. At the 28th day, under the same conditions (no loading), the Based on the The compressive and splitting tensile strength test results of the blocks that had been loaded on the 28th day under the three curing conditions are shown in From the above test results, steam curing significantly improved the early compressive strength of the concrete, while the compressive strength of the steam-cured concrete was lower than that of the standard-cured concrete after 28 days. The reasons for the compressive strength changes were as follows: During steam curing, the hydrated products of the hydrated calcium silicate gel grew denser, and they were unable to effectively fill the pores, which decreased the porosity and strength of the hardened concrete. The naturally cured concrete presented the lowest value for each aging condition due to its poor curing conditions, lower temperature, and humidity compared to the other two curing conditions.For the splitting tensile strength shown in Based on the above experimental results, the effects of the curing conditions on the concrete strength were comprehensively studied. It was concluded that in the initial stage, the steam curing condition significantly improved the strength of the concrete, followed by the standard curing condition, and the natural curing condition presented the weakest performance. At the 28th day, the strength of the standard-cured concrete was higher than that of the steam-cured concrete. After 28 days, the rate of the increase in the strength of the standard-cured concrete was higher than that of the steam-cured concrete. As the age increased, the increasing rate of the splitting tensile strength was lower than that of the compressive strength, indicating that the brittleness of the concrete increased as the age increased.The methods for calculating fracture toughness given in ,25.(1) The fracture toughness Steam curing can significantly improve the early fracture toughness of concrete. After 28 days, the standard curing condition was better than the steam curing in improving the fracture toughness (2) The critical crack tip opening displacements The effect of the curing condition on the Based on (3) The critical strain energy release rate The results showed that the steam curing significantly increased the growth rate of (1)Material length Q were applied as the criteria for concrete brittleness, and the relevant theories are given in [The characteristic length given in . The mat(2)Tension–compression strength ratioThe tension–compression strength ratios of the cured concrete are shown in Based on the tension–compression strength ratio data before the 28th day, a clear development trend could not be obtained. Therefore, the tension–compression strength ratio was suitable for evaluating the brittleness development from a long-term perspective, but not for that at an early age.In the steam-cured concrete, the thermal effect weakened the transition zone in the concrete and caused fracture toughness In the steam curing process, the hydration reaction was intensified during the initial stage. A thick hydrate-shielding film formed on the surface of the particles, immediately leading to a decreased hydration rate, and the shielding film became denser with further hydration. The density of the gel increased by 15–20% compared to that at normal temperatures. This indicated that the shielding film could not be permeated easily and that it blocked the internal diffusion of the hydration system inside the concrete, which affected the reaction rate and extent of the concrete during the later hardening stage.Under the steam curing condition, the size of the hydrated crystals increased as the curing temperature increased, forming coarse-grained structures, and the specific surface area of the hydrated crystal decreased, resulting in a decrease in dispersion. The large crystals adversely affected the strength and toughness of the concrete structure. As the temperature decreased, the specific surface area and unit volume concentration of the hydrate increased, and the contact points between the particles increased. The binding forces between the particles were mainly determined by van der Waals interactions and electrostatic forces. The increase in the number of contact points between the particles resulted in an increase in cohesive forces. Therefore, the critical crack tip-opening displacement of the steam-cured concrete was less than the corresponding value of the standard-cured concrete in the later stages.The reason for the decrease in the Standard curing improved the When loaded at an early age, a damage zone occurs in the concrete, and the damage zone will evolve into a critical state, followed by the creation of macro cracks. The damage and fracture of a concrete structure is a continuous process, and the energy release rate is the link between damage and fracture. In the critical state, the relationship between concrete damage and fracture can be established by their common relationship to the energy release. The previous experimental results reveal the effect of the loading age and the curing condition on the strength, fracture property, and brittleness development of concrete. Being able to accurately predict the long-term performance of concrete under the coupled effects of loading and curing is of great significance. Therefore, it is necessary to establish a time-dependent model of concrete fracture toughness under the coupled effect of loading and curing.A time-dependent model of concrete fracture toughness that considers the curing conditions and the loading ages is proposed to predict the fracture properties of concrete. The model’s derivation process is described in this section.The fracture criterion for crack instability propagation is In the critical state, the relationship is given by Equation (2):In fracture mechanics, the criterion for fracture is Based on Equation (3), When the tensile stress (1) The crack-tip damage zone in concrete is the transition zone at the crack tip, which is a micro-crack zone that is caused by tensile stresses. It is appropriate to use the maximum tensile stress theory to study the mode I crack of concrete.Based on the maximum tensile stress theory:(2) The damage strain energy release rate For damaged materials, the elastic strain energy is given by:The elastic complementary energy is given by:The damage strain energy release rate is:Equation (9) is obtained after tensor calculus:Therefore, the hydrostatic pressure can be determined by Equation (11) can be obtained from Equation (9):Therefore, a mode I crack under uniaxial stress can be expressed, where Where Equation (13)’s equivalent stress is (3) The following is a discussion on the relationship between The cracks are generated in the damage zone and are accompanied by the release of energy. When the material is damaged by loading, the damage deterioration process will be shortened, accelerating the fracture of the material.Equation (14) presents the energy relationship in the critical state:Equation (14) expresses that (4) The damage and fracture coupling of the mode I crack are analyzed in this section. The tip of the mode I crack exists as a microcrack damage zone, the shape and size of this zone are depicted in For a mode I crack, the expression of (5) The equivalent principle of effective stress and strain can also be obtained. In damage mechanics, the damage variable is defined as the ratio of the damaged area Without considering the material damage, the elastic constitutive equation without considering material damage is The stress–strain relationship of the damaged concrete is given by Equation (19):The expression of the mode I crack stress intensity factor of concrete considering damage is:The effective stress of the materials can be expressed by Equation (21):Additionally, the constitutive relation follows:(1) To assess the damage caused by immediate strain, the Loland damage model considers the initial damage of materials and considers that the damage will occur when the load is applied, which indicates that the damage evolves gradually under load.The data obtained from the uniaxial tensile test of concrete were fitted, and the damage evolution is given by Equation (24):According to , the criThe above data are substituted into Equation (23); therefore, (2) The creep deformation caused by the load increases the internal strain energy of the material. When the accumulated strain energy exceeds a certain limit, some strain energy is released due to the micro-crack and will be converted into the surface energy of the crack, which causes crack initiation and expansion inside the concrete. The overall elastic modulus of the concrete decreases with the development of microcracks; thus, creep deformation increases. The coupling effect of damage and creep causes the cracks to develop more rapidly, leading to concrete failure. Based on the statistical damage constitutive model and the randomness of defect distribution, the internal damage The damage variable Assuming that Equation (27) is substituted into Equation (28), and the damage variable Based on Equation (29), determining the micro-unit strength Based on the test, (3) Tensile creep The creep of concrete under For the compressive strength of concrete at the 28th day The creep coefficient of concrete is given by Equation (33):(4) The immediate strain of concrete The coupling effect of temperature and time can be considered according to maturity, and the relationship between fracture parameters and maturity can be established.The previous experimental data and discussion indicated that the fracture toughness was approximately logarithmic with the age, and this regulation was consistent with the research results that have been obtained by many scholars. For example, the research conducted by Mi Zhengxiang  showed tIn this study, maturity was introduced to include the effects of curing condition, temperature, and age on fracture characteristics. Combined with the fracture test results of the concrete under different curing conditions at each age, the relationship between fracture parameters and maturity of the concrete was studied. Finally, a relationship between fracture toughness and the equivalent maturity of the concrete was obtained.t is the total time, d; and Nures  and SaulThe concrete maturity was calculated by Equation (44), and the development model of the fracture toughness for concrete maturity was established in . HoweverBased on the double-broken line relationship between fracture toughness and compressive strength from , the effIn Equation (44), the temperature is the internal temperature of the concrete. Because the specimen was small, the internal temperature of the concrete could disperse quickly, and the increase of temperature was not high. Ni Tongyuan  found thFor three days of steam curing, the temperature was 45 °C, and natural curing was applied from the 3rd to the 28th day, the temperature was 45 °C, and the equivalent temperature was By substituting the equivalent maturity into the relationship between the maturity and stress intensity factors, the change in the stress intensity factor with time under different curing conditions could be obtained:The time-dependent model of concrete fracture toughness under different curing conditions and continuous load could therefore be expressed by:In Equation (50), Some parameters in Equation (50) need to be determined, and The experimental value of the crack propagation resistance Based on From All of the unknown parameters in the time-dependent model of concrete fracture toughness are obtained. The time-dependent model of concrete fracture toughness under different curing conditions and loading ages can thus be described by substituting the parameter values into Equation (50).Equation (50) was verified by the experimental results of crack propagation resistance of the cured concrete under different curing conditions. The measured As observed in In addition, the fracture toughness ata from ,35 were ata from ,35 are sata from ,35 due tIn In In conclusion, the model can accurately predict the development of concrete fracture toughness.In this study, the effect of the curing condition and loading age on the mechanical, fracture, and brittleness properties of concrete was investigated at four different ages . Steam, standard, and natural curing conditions and loading ages of 3, 7, and 28 days were considered. A time-dependent model of concrete fracture toughness that considered the effects of the curing condition and the loading age was established. The key parameters were calibrated based on the test data, and the suitability of the model was investigated. The conclusions can be summarized as follows:(1) Based on the P-CMOD curves of the concrete samples that were created under different curing conditions, steam curing improved the early strength of concrete but weakened subsequent strength in the later stages. Based on the crack initiation load and load limit of the concrete, the steam curing condition significantly improved the early bearing capacity of the concrete and had adverse effects on its later strength. The standard curing condition had a better effect on the later bearing capacity of the concrete, and the natural curing condition had a weaker effect on the early and later bearing capacity of the concrete compared to the abovementioned two curing methods. Based on the results of the strength tests, it was shown that steam curing significantly improved the early compressive strength and the splitting tensile strength of the concrete. The compressive strength and splitting tensile strength of the steam-cured concrete after the 28th day were lower than those of standard-cured concrete, and the corresponding strength of the naturally cured concrete was always the lowest.(2) Based on the fracture toughness of the concrete (3) The material length (4) A time-dependent model of concrete fracture toughness that considered the curing condition and loading age was established. Based on the comparisons between the model predicted value and the test values that were obtained from other studies in the literature, the error is acceptable. The proposed model presents strong adaptability and is able to accurately predict the development of concrete fracture toughness.


To explore antibiotic consumption and surveillance patterns in Trinidad and Tobago.A retrospective observational study was conducted. Stock requisition and logbooks from a District Health Facility in Trinidad were examined for the period 2011–18. Daily Defined Doses (DDDs) for each antibiotic were computed and extrapolated to represent the antibiotic consumption per 1000 residents within the population.The mean consumption across the years was 2.917 DDD per 1000 residents per day. The most consumed antibiotics were cefuroxime, amoxicillin/clavulanic acid, and azithromycin, with mean DDDs of 0.879, 0.695 and 0.373 respectively. The least consumed antibiotics were cefaclor and clarithromycin, with DDDs of 0.0006 and 0.0005, respectively.Trinidad and Tobago is not mentioned in the WHO surveillance report on antibiotic consumption. Our most recent (2018) estimate of total antibiotic consumption was 3.224 DDD per 1000 habitants per day. This figure is an underestimate, as data was derived solely from the public sector. Notwithstanding, this data is novel and can provide a baseline for future comparison and development of national surveillance programmes. The Global Action Plan (GAP) on antimicrobial resistance was adopted by member states at the World Health Assembly in 2015. One of the objectives of the GAP is to optimize the use of antimicrobial medicines, thereby underscoring the importance of monitoring the consumption of antimicrobials. Data on the consumption of antimicrobials have several uses, including exploring the relationships between exposure to antimicrobials and the development of antimicrobial resistance (AMR).,The emergence and dissemination of antibiotic resistance is now understood to be an unavoidable aspect of bacterial evolution following the consumption of antibiotics.Resistant bacteria are expected outcompete other microbial communities in a context where antibiotics are administered at relatively high levels, which means that local concentrations are well above the MICs. This awareness has led to series of reports and recommendations that intend to educate and improve practices of health professionals and consumers, in order to preserve the effectiveness of our therapeutic armamentarium.Recently a Caribbean-wide point prevalence survey showed high usage of β-lactam antibiotics, especially third-generation cephalosporins, as well as quinolones, macrolides and a considerable degree of carbapenem usage.In Trinidad and Tobago, extensive and inappropriate use of third-generation cephalosporins has been documented in a tertiary care setting.per se and not to all antimicrobials. Therefore, agents such as co-trimoxazole and the quinolones, which do not fall under this regulation, are available without prescription. It is widely known that antimicrobial agents can be obtained at pharmacies without a prescription, and pharmacists simply dispense these drugs as over-the-counter medications in response to requests from customers.An appreciation of the need to have this usage quantified can be gleaned by understanding the culture and practice of the local pharmacies within Trinidad and Tobago. The service is divided between the public and private sectors. There are public hospital outpatient pharmacies, which are funded by the government, and private pharmaceutical companies. The country’s Food and Drugs Act classifies antibiotics as controlled drugs to be dispensed by prescription only. An anomaly in the law is its strict application only to those drugs defined by the term ‘antibiotics’ This report is novel as it establishes antibiotic consumption patterns within a community setting in Trinidad and Tobago. Trinidad and Tobago’s last population count was 1 324 699 people (2011 census). The community of Chaguanas where this study was conducted has a population of 84 216 and this number was used in computing consumption rates.Data was collected from the stock requisition and logbooks at a primary care-based outpatient public sector District Health Facility in Trinidad, namely the Chaguanas District Health Facility. This was done in the months of January to June 2019.Stock requisition and logbooks for the years 2011–18 were examined. Antibiotic consumption data was computed using the ATC classification system and Defined Daily Dose (DDD) methodology that was developed by the WHO.Data was extrapolated to represent the antibiotic consumption per 1000 residents within the study population per day (DID) to standardize the reporting metric for comparison with other estimates. Data was subsequently inputted into Statistical Package for the Social Sciences Version 23 for analysis.Ethics approval was obtained from the University of the West Indies and the North Central Regional Health Authority with jurisdiction over the operations of this facility.Analysis of the mean DDDs revealed that the most-consumed antibiotics were cefuroxime, amoxicillin/clavulanic acid, and azithromycin, consecutively. The least-consumed antibiotics were clarithromycin and cefaclor Figure.The mean of total consumption across the years for all antibiotics consumed was 2.917 DDD per 1000 residents per day. The highest total consumption was in 2013, with 4.603 DDD per 1000 residents per day, and the lowest total consumption was reported in 2014, with 1.986 DDD per 1000 residents per day recorded Figure.The most-prescribed antibiotic was cefuroxime with 7.036 DDD per 1000 residents per day. Amoxicillin/clavulanic acid was the second-most-prescribed antibiotic with 5.558 DDD per 1000 residents per day. Azithromycin was the third-most-consumed antibiotic accounting for 2.283 DDD per 1000 residents per day.Internationally, projects have been undertaken to collect antibiotic usage data through national surveillance systems. In the absence of a national surveillance system with a repository of such data, we have collected and analysed data over an 8 year period, thereby generating useful baseline metrics that can be extrapolated and from which meaningful conclusions can be drawn. Indeed, similar work, albeit on a larger scale, performed by the European Study on Antibiotic Consumption (ESAC) project produced a valid time series of antibiotic-use data. Those data enabled improvements to the study of determinants of use, the evaluation of governmental antibiotic consumption policies and the investigation of the associated emergence of antibiotic resistance.The computation of DDDs allows for comparison locally and internationally, thereby facilitating informed decision making as it relates to antibiotic procurement and prescribing, and provides a basis for antimicrobial resistance and stewardship programmes.Our DDD computations came from the public sector arm of one ambulatory primary care-based facility and does not account for private sector or inpatient consumption. This therefore reduces our ability to generalize and extrapolate this metric in order to estimate national levels of antibiotic consumption. On the other hand, the fact that our data was sourced from public records suggests reasonable levels of documentation and distribution, thereby enhancing the validity and reliability of our findings.The only metric available for comparison with neighbouring countries is that for public sector only antibiotic consumption recorded by Costa Rica in 2016 of 14.18 DDDs.In Trinidad, antibiotic prescribing is regulated by the Antibiotics Act chapter 30:02.With regards to the pattern of consumption, WHO has stated that in most countries, amoxicillin and amoxicillin/clavulanic acid were the most frequently consumed antibiotics; these belong to the Access category of the Model List of Essential Medicines, which includes antibiotics recommended as first- or second-line therapy for common infectious diseases and that should be available in all countries.The finding of cefuroxime being the most-consumed antibiotic is concerning as it belongs to the Watch group of antibiotics with high resistance potential compared with those belonging to the Access category. A study from India also found cefuroxime to be amongst the most commonly prescribed antibiotics. The authors went on to state that although second- and third-generation cephalosporins offer several advantages, their use could be attributed to combination of factors such as changing prescribing practices, increasing antimicrobial resistance to other antibiotic classes and lack of availability of first-line penicillin antibiotics belonging to the Access group.Vibrio fluvialis isolates from diarrhoeal patients in Kolkata, India.Azithromycin also belongs to the Watch group of antibiotics. The second highest level of consumption of 2.13 DDDs per 1000 inhabitants per day was reported in the Austrian primary care sector in the year 2019.Our findings provide useful insight into the quantities and patterns of antibiotics used in our country. It is recommended that further research be undertaken involving the private sector and secondary/tertiary care settings in order to obtain a better estimate of national consumption levels.It is envisaged that these unprecedented findings will assist in the development of a national system for antibiotic consumption and surveillance as recommended by the WHO. It is also recommended that local antimicrobial resistance patterns be explored and related to our findings in order to pioneer national antimicrobial stewardship programmes that will reduce levels of antibiotic resistance, enhance patient outcomes and ultimately provide more cost-effective care of infectious diseases.


Techniques of non-invasive brain stimulation (NIBS) of the human primary motor cortex (M1) are widely used in basic and clinical research to induce neural plasticity. The induction of neural plasticity in the M1 may improve motor performance ability in healthy individuals and patients with motor deficit caused by brain disorders. However, several recent studies revealed that various NIBS techniques yield high interindividual variability in the response, and that the brain-derived neurotrophic factor (BDNF) genotype  may be a factor contributing to this variability. Here, we conducted a systematic review of all published studies that investigated the effects of the BDNF genotype on various forms of NIBS techniques applied to the human M1. The motor-evoked potential (MEP) amplitudes elicited by single-pulse transcranial magnetic stimulation (TMS), which can evaluate M1 excitability, were investigated as the main outcome. A total of 1,827 articles were identified, of which 17  and 10  were included in this review. More than two-thirds of the data (70.4–78.6%) on both NIBS protocols did not show a significant genotype effect of NIBS on MEP changes. Conversely, most of the remaining data revealed that the Val/Val type is likely to yield a greater MEP response after NIBS than the Met carrier type in both NIBS protocols (21.4–25.9%). Finally, to aid future investigation, we discuss the potential effect of the BDNF genotype based on mechanisms and methodological issues. Non-invasive brain stimulation (NIBS) to the primary motor cortex (M1) induces neural plasticity and is being used ubiquitously as a leading-edge neurorehabilitation tool. Methods of NIBS, including magnetic stimulation or electrical stimulation to the M1 through the scalp, can temporally control M1 excitability toward an increased or decreased value  measurement with MEP is commonly used to non-invasively assess the M1 excitability changes induced by the NIBS protocol. Although it is still controversial whether the MEP changes induced by NIBS are associated with motor performance, MEP can capture the M1 plasticity changes via comparison of the amplitudes. Thus, we aimed to investigate the functional difference on the M1 plasticity using MEP at a neural level. If the NIBS effect varies depending on the genotype, the secretion of BDNF could contribute to this difference. Therefore, this review also discussed the mechanisms via which the difference in BDNF secretion modulates the M1 plasticity after the NIBS protocol. Furthermore, to aid future investigation, we raised some methodological issues in studies that investigated the effect of the genotype on NIBS based on the assessment of the collected articles.This systematic review was conducted according to the guidelines of the Preferred Reporting Items for Systematic Reviews and Meta-analyses for Protocols 2015 (PRISMA-P 2015)  peer-reviewed articles published in English; (2) articles reporting studies performed on healthy adult humans (but not the elderly) not taking any psychoactive medications or drugs; (3) articles that received formal ethical approval; (4) the outcome had to include subjects who were classified into BDNF genotype groups and underwent MEP measurements with single-pulse TMS before and after the NIBS protocol (within 24 h); (5) rTMS, TBS, tDCS, transcranial alternating current stimulation (tACS), transcranial random noise stimulation (tRNS), PAS, and quadri-pulse stimulation (QPS), which can modulate M1 excitability, were selected as a NIBS protocol; (6) the outcomes were obtainable from the main text, figures, tables, or supplementary data; (7) one NIBS protocol was administered to the M1 as an intervention, expect for a combination of NIBS and sham  or resting condition (rTMS+resting condition); (8) first pre/post measurements were included in cases of a NIBS protocol that aimed at homeostatic plasticity using two interventions at different time points; and (9) TMS was performed on the left M1 or right M1, and MEP was recorded from the contralateral side. The titles and abstracts of the articles were initially screened by one reviewer (R.S). Eligibility of the studies was determined independently by two reviewers (R.S and S.K), who assessed the full text against the inclusion and exclusion criteria.A literature search was conducted using the scientific databases PubMed and Web of Science on April 21, 2021 for articles published from January, 2000 to April 21, 2021. The following search terms were included in these combinations: “transcranial direct current stimulation,” “repetitive transcranial magnetic stimulation,” “theta burst stimulation,” “paired associative stimulation,” “transcranial alternating current stimulation,” “transcranial random noise stimulation,” or “quadri-pulse stimulation” + “brain-derived neurotrophic factor,” “BDNF,” or “Val66Met.” Furthermore, a manual search was carried out over the reference sections of the retrieved studies.P-values < 0.05 were taken as a measure of statistical significance. First, we used ANOVA or t-test to evaluate the effect of NIBS on MEP changes for each genotype group by comparing the MEP changes between the pre and post data before and after the NIBS condition or NIBS and sham conditions obtained from the results of the selected articles. We established the existence of a facilitatory or inhibitory effect of NIBS for each genotype group if a significant difference was observed by ANOVA or t-test. Second, the effect of genotype on NIBS-induced MEP changes was assessed. Most of the selected articles used ANOVA to assess the main effect of time and genotype, as well as the interaction. If the main effect of the genotype group or the interaction was not significant, we judged that no effect of the genotype was observed on MEP changes based on the NIBS protocol, even if there was a trend. If different effects were observed between time points or genotype groups by post hoc analysis after ANOVA, we established that there was a significant difference between the genotype groups. A few articles used t-test without ANOVA to assess the effect of the genotype on MEP changes before and after NIBS. In this case, if a different effect was observed between the time points  for each group or between groups, we judged that there was a significant difference.The MEP amplitudes elicited by single-pulse TMS were investigated as main outcome measures. The The risk of bias was assessed using the Cochrane Collaboration's tool , Val/Met (N = 2), or Met/Met (N = 3) [1 datum compared between three genotypes, and the result showed that there was a significant difference between Val/Val and Val/Met or Met/Met , Val/Met (N = 1), or Met/Met (N = 3) carriers from 7 out of 8 data [1 datum compared between three genotypes, and the result showed that there was a significant difference between Val/Val and Val/Met or Met/Met , Val/Met (N = 1 datum), or Met/Met (N = 0 data). The expected inhibitory MEP response after the inhibitory NIBS protocol was greater in the Val/Val than in the Non-Val/Val (N = 2 data), Val/Met (N = 1 datum), or Met/Met (N = 0 data) from three data, with a significant difference (21.4% in 14 data) . Given the genotype-related functional changes in the brain between Val/Met and Met/Met carriers, in addition to the small sample size, future studies including the three groups and a large sample population are required. None of studies reporting inhibitory NIBS data classified participants into three groups.Few of the selected articles classified participants into three genotype groups in the facilitatory NIBS protocol. High-frequency rTMS, which induces MEP facilitation, had a poor facilitatory effect in the Met/Met group compared with Val/Val and Val/Met groups , suggesting that tDCS, rTMS, and PAS were performed less frequently in the inhibitory NIBS protocol  than in the facilitatory NIBS protocol . Taken together, to investigate the genotype-related changes in detail, further studies investigating a variety of NIBS protocols are warranted.We assessed the risk of bias based on Cochrane Collaboration's tool  from the Japan Society for the Promotion of Science (grant number 19H01090) and Overseas Research Fellowship from the Japan Society for the Promotion of Science (grant number: 202060103).The authors declare that the research was conducted in the absence of any commercial or financial relationships that could be construed as a potential conflict of interest.All claims expressed in this article are solely those of the authors and do not necessarily represent those of their affiliated organizations, or those of the publisher, the editors and the reviewers. Any product that may be evaluated in this article, or claim that may be made by its manufacturer, is not guaranteed or endorsed by the publisher.