Our Automation Elements are sourced from a community of experts around the world. For example, all of our Auto-Detect Elements (ADEs) for F5 devices were written by F5 experts. These experts have been using F5 devices for years, they are certified on the devices they write scripts for and some of them are even F5 DevCentral MVPs.

When code is contributed by engineers from around the world, it is vital to ensure the code is of high quality. It is equally important to ensure the code is developed according to global best practices and reflects the results you’d expect from a superb team. Just like the Linux kernel open source project, which all businesses depend on today, has a strict development process and quality controls, so does Indeni’s automation repository.

The developers that contribute to our platform today come from the US, Israel, Canada, United Kingdom, Sweden, Spain, India and Greece.

Overarching Process

The overarching Indeni Automation Element creation process follows these steps:

1. Automation idea or request (“collaborate”) – a community member suggests an Automation Element (script or rule) to add to the repository, or a current user of Indeni asks for one. This idea or request is logged as a ticket (what we call “IKP Ticket”).
2. Ticket assigned – one of the pre-vetted contributors (see below “Contributor validation”) is assigned the ticket.
3. Script developed and tested (the “code”, “build” and “test” phases) – the contributor writes the Automation Element and follows the guidelines set for code review, testing and code contribution set by Indeni. Please see “quality controls” below.
4. Script release (“release” and “deploy”) – the Automation Element is included in the next update package and is released to customers around the world. It is deployed with a click of a button as part of the package.
5. On-going element utilization analysis and feedback collection (“automate” and “analyze”) – the Automation Elements behavior is continuously watched through Indeni Insight. We identify how many issues the Auto-Detect or Auto-Triage Element is helping identify, how well is it performing and what types of devices it is being used with. We also solicit user feedback to ensure the script is doing what a user would expect it to.
6. Feedback recorded and actioned (“collaborate”) – the feedback (both machine and human) is recorded as new IKP tickets, which are then assigned to community contributors and the process starts anew.

New content is released every quarter. Bug fixes are released once a month if needed.

Quality Controls

Our pre-distribution quality controls include:

• Contributor validation – each contributor is personally validated. We inspect their resume, talk to them and ensure they are truly experts in their field. We also verify their legitimacy to weed out bad actors. During the validation process, we provide them with challenges to ensure they can handle the work.
• Curation – we specifically select which Automation Elements make it into the repository and which don’t. There is not a single element that gets included without sign-off by an Indeni employee.
• Double human verification – each Automation Element goes through a code review process by a designated community member. Those who are allowed to conduct the code review are very experienced, and are generally pedant, catching small errors.
• Manual testing in a lab – every element is manually tested against one or more devices which it supports, to ensure it works properly and does not impact the device negatively. There are two labs these are tested in, one in Tel Aviv and one in San Francisco, as well as mini-labs maintained by certain community members.
• Automated verification – an automated system, based on the Jenkins Continuous Integration / Continuous Delivery tool, ensures that each script has automatic tests and conforms with our standards.
• End-to-End System Integration testing – Our Automation Elements are built into the platform by Indeni Engineers (Tel Aviv) before every release and tested end-to-end via an internally developed system.
• Beta phase – certain elements, such as scripts, or groups of scripts, will go through a beta phase. In this phase, customers and users may volunteer to test the scripts with their devices before they become production Auto-Detect Elements (ADEs) or Auto-Triage Elements (ATEs).

An ADE or ATE must go through all of the quality controls in order to be accepted and released into the Indeni Platform.

Hybrid Open and Control Solution

Our open development platform gives you immediate access to an entire knowledge base and enables security engineers to collaborate and contribute knowledge in the forms of scripts and rules. Similar to other open source solutions Indeni provides an open development process. Unlike open source we offer an out of the box solution through an annual subscription to our platform. The hybrid open nature of the Indeni Platform provides efficient knowledge sharing, helping your organization grow its automation assets. At the same time, by putting the world’s knowledge through a controlled development process, we ensure consistent, enterprise quality content is delivered to you on the Indeni Security Infrastructure Automation Platform.