Key Exploitable Results

The significance of software has recently grown to the point of merging the role of software developers with that of infrastructure operators, of which the main focus is the automation of infrastructure-related activities through the use of trustworthy software (secure, correct and reliable IaC), giving birth to the Infrastructure as Code trend considered as  the engine of the DevSecOps movement.

DevSecOps is an organizational change that consists of using software engineering tactics that reduce the technical and organizational distance between development and operation, leading to the creation of a single, well-coordinated team of people. It also stands for the correctness, trustworthiness and security of the code along all its development and operation lifecycle.

Figure 1. PIACERE KRs’ value chain

Our main goal is to allow the DevSecOps team to work with infrastructural code as they do with traditional application code, starting from the definition of requirements for the infrastructure – such requirements are expressed in terms of technical capabilities the application-level software should offer – to the design, implementation, verification, deployment, testing, operation and monitoring of such infrastructural code.PIACERE is designing and implementing tools for IaC developers to realize the DevSecOps approach a set of Key Results (KRs) [include the link to KRs].   

As part of the PIACERE exploitation strategy we have grouped these KR into exploitable Results (i.e., the inovation assets produced in the lifetime of the project with biggest potential both in a OSS community context or in a commercial context) into the three phases Dev/Sec/Ops.

We have also prioritized them based on the internal analysis in the consortium and considering different relevant aspects such as IP rights, interest from the partners on the commercialization, market watch and competitors’ analysis among others.

As part of this reflection , we have ended up with the first triplet of PIACERE Key Exploitable Results, one per phase for which a detail exploitation roadmap has been designed. In the upcoming months, new Key Exploitable Results will be incorporated to this list, enriching the dimensional view of each KER.

DESIGN TIME

KER1 DOML

PIACERE DevSecOps Modelling Language

Improve the ability of (non-)expert DevSecOps teams to model provisioning, deployment and configuration through the abstraction of execution environments

DOML is the end-user language enabling the modelling of deployment and configuration of complex software and of the corresponding infrastructure.

The modeling activity is performed in the context of the PIACERE IDE that helps users in defining syntactically correct models. Moreover, it is supported by the Verification Service that helps DevSecOps teams in identifying and fixing conceptual errors and by the Optimization Service that, given a DOML model, returns the set of concrete resources that best suit the expressed non-functional requirements. Correct DOML models can then be transformed by ICG in executable IaC supporting resource provisioning and configuration as well as application deployment, monitoring, and self-healing.

Finally, the DOML offers extension mechanisms that allow users to define new resource types or extend the existing ones in order to cope with the evolution of the market in the DevOps context.  

 

KER2 Design Time Sec

PIACERE Design Time Security

Regain trust in IaC through the DOML verification and the automation of IaC code quality checking for errors and vulnerable dependencies, and thus improving IaC integrity and applicability

The ICSI technology can check the IaC code for errors and report back to the user with a set of error reports and also recommendations where inefficiencies are in his code. With it PIACERE is addressing the lack of tailored solutions for checking the integrity and applicability of IaC code to be deployed on an infrastructure provided by the verification tools, leading to very limited trust in the automated deployment systems.

RUNTIME

KER3 Execution

PIACERE IaC Execution Manager

Avoid vendor lock-in and time consuming manual processes in infrastructure management, while increasing resilience and supporting self-healing

IEM is helping to develop and maintain infrastructure as code for heterogeneous infrastructures and different phases (configure, provision, deploy, orchestrate), supporting multilingualism with one tool. It is a platform to automatically plan, prepare, and provision the infrastructure and plan, prepare, and install the software elements needed for the application to seamlessly run.

 

KER4 Optimisation

PIACERE IaC Optimized Platform

Perform the most appropriate deployment configurations that best meet your defined constraints out of DevSecOps catalogue of services, resources and infrastructural elements by means of optimization algorithms.

The IOP is able to propose the most optimized deployment configuration of the infrastructural code taking into consideration the constraints predefined. To this end, several deployment configurations will be shown and ranked.

 

KER5 Sandbox

PIACERE Canary Sandbox

Allow unit testing of the behaviour of the infrastructural code on an isolated environment, which would enable the simulation of conditions for the production environment and identify some of the most common anti-patterns.

The Canary Sandbox Environment enables isolated execution and testing of Infrastructure as Code behaviour (i.e., Kitchen), simulating the conditions of the production environment, and offering a stress testing mechanism focused on the reliability of the generated IaC as well as on the identification of possible cybersecurity threats.

 

KER6 Runtime Sec

PIACERE Runtime Security

Ensure that the conditions of the QoS are met at all times and that a failure or non-compliance of NFRs is not likely to occur, with verified security violations at runtime.

PIACERE at runtime is able to automatically deploy security monitoring agents, integrated into the monitoring mechanisms and notify about security threats according to the policies, defined in the NFRs; allowing for self-learning and self-healing, and tackle unexpected situations that may affect the correct performance of IaC and its underlying environment (i.e. infrastructure failures, deterioration in the response time, etc.).