One continually evolving attack vector for nefarious actors is the software supply chain, particularly within open source software package solutions and repositories.  Many of these exploits are not sophisticated, but they are particularly potent due to their ease of execution, potential wide impact across organizations and projects, and difficulty to detect.  These exploits include, but are not limited to:

• RepoJacking – identifying vulnerable legitimate open source repositories (e.g., no 2FA authentication) and using brute-force or phishing tactics to secure access to the project and surreptitiously adding code or dependencies without the original authors or consumers noticing. Additionally, attackers have leveraged the user renaming capability within GitHub to take over a previously legitimate project.
• StarJacking – effectively “cloning” the star rating/download numbers of an upstream project to lend (false) credibility to a nefarious package (e.g., creating a new package on PyPi and sending PyPi metadata indicating it is a fork of a legitimate project, whereas in fact it is not).
• TypoSquatting – creating malicious packages with names derived from other popular reputable packages in the hopes that developers typo the name in their package manifests and pull the malicious package on accident (e.g., attackers naming an NPM package reqest, reuqest, requesst in hopes a developer makes a mistake an imports the attacker’s package rather than the legitimate one)
• Dependency Confusion – cloning the code from a legitimate project and simply adding an otherwise unneeded package dependency on a malicious package. This attack can be implemented by RepoJacking or an iteration on the above Typo Squatting.
• Source Control Action/Automation Manipulation – leveraging CI automation tools (e.g., GitHub actions) to automatically build and run malicious code during push or release actions

Checkmarx team of researchers and engineers proactively pull down and test thousands of packages published weekly within a dedicated “detonation chamber” environment to identify and index nefarious or exploited packages and we report our findings to the relevant package management platform.  In our testing, we have observed many of these exploits occurring “in the wild,” and while there are no clear-cut solutions, there are relatively small actions we as open source community members can take to avoid hackers from exploiting the fruits of their spoils. These actions include (but are not limited to):

• Developers can ensure they only import dependencies (and those dependencies’ dependencies) that are needed.
• Developers can ensure our package manifests are free of typos and are using strict versioning so as to prevent automated upgrading of packages
• Developers can leverage both static and dynamic code scanning and SCA analysis to identify vulnerabilities early and ensure their projects and software are not “calling home” to unknown destinations
• Open source developers can implement 2FA for their open source software project repositories to prevent brute force attacks and takeover of projects
• Package and repository solutions (e.g., NPM, Pypi, GitHub) can enforce project forking tracking and improve project credibility enforcement to prevent or mitigate StarJacking
• Package and repository solutions, open source developers, and security organizations can establish and agree upon a common standard for identifying and flagging malicious software packages and repositories to improve identification, detection, and removal of malicious software packages and code (target resolving the “Package Naming Problem”)

Ultimately, improving security within the open source community is our responsibility as developers, project contributors, and stewards. Checkmarx can help you and your organization protect your applications from software supply chain vulnerabilities through our suite of application scanning tools such as Checkmarx Supply Chain Security offering (SCS), SAST, and KICS, all of which are available as services within the integrated Checkmarx One platform. Often, and given the nature of supply chain attacks, we need to correlate the results from multiple scans to identify vulnerabilities or malicious code within our projects.

With Checkmarx Fusion correlation engine integrated within Checkmarx One, we automate and illustrate the results from these multiple scans to make it simple and easy for developer teams and information security teams to identify and remediate quickly. Lastly, be sure to check out our open source tool, ChainJacking, which can help you identify which of your direct GitHub dependencies are susceptible to RepoJacking attacks.

For more information, watch our recent session at The Linux Foundation Open Source Summit North America entitled The Simple, Yet Lethal, Anatomy of a Software Supply Chain Attack presented by Jossef Harush, Head of Engineering of Supply Chain Security at Checkmarx. Additionally you can download the Understanding Open Source Supply Chain Attacks whitepaper.

IaC tools are now available for many different infrastructure providers ranging from traditional virtual machines to Kubernetes clusters and containerized applications.

One advantage of IaC is that all techniques that are usually aimed at source code (e.g., unit tests, linting, security scanning) can now be applied to infrastructure as well.

Static Analysis with Checkmarx KICS

Static analysis of infrastructure is a particularly important aspect of a secure workflow, as errors in infrastructure can result in unplanned downtime, to having security issues in production environments.

KICS (Keeping Infrastructure as Code Secure) is a free, open source solution for static code analysis of IaC powered by Checkmarx.

KICS automatically parses common IaC files of any type to detect insecure configurations that could expose your applications, data, or services, which are deployed on the cloud, to attack. That means you can let anyone on your team write IaC files, and then vet the files to ensure they are secure before deployment.

Instead of setting security guidelines in your IT governance policies and hoping engineers and developers follow them when creating IaC files, you can automatically enforce IaC security with KICS.

KICS is an open source tool that supports all mainstream IaC platforms like:

• Terraform
• CloudFormation
• Azure Resource Manager
• Google Deployment Manager
• Ansible
• Kubernetes/Helm manifests
• and more

KICS also integrates with a variety of software development tools and makes it possible to add IaC security scanning to your existing workflows without friction.

As an open source, platform-agnostic IaC scanning tool, KICS can grow seamlessly along with your development and deployment operations.

Developers can extend KICS with new checks and policies using a simple, industry-standard query language (REGO). In addition, developers can quickly onboard new items to automated scanning workflows while also extending IaC scanning capabilities into new parts of their application stack or new types of IaC resources by taking advantage of KICS’ modular design.

KICS also enables organizations to keep up with security best practices and comply with CIS benchmarks such as “CIS Amazon Web Services Foundations Benchmark version 1.4.0, Level 1” or level 2.

For more details on KICS refer to:kics.io

Automating Static Analysis with Codefresh

KICS offers several ways to run it out of the box. You can run it from the command line, via a Docker container, or even try it from a web interface. For a production environment however, an automated workflow where a deployment pipeline is running KICS as part of the full infrastructure lifecycle is strongly recommended. A logical way to run KICS  would be as part of a Continuous Integration (CI) process resulting in repeatable scans against any change in infrastructure files.

The Codefresh Software Delivery Platform includes a Continuous Integration component that can easily run KICS in an automated way using any of the supported triggers. As a very simple example, if a developer changes a Kubernetes manifest for an environment, KICS  should be executed as part of the commit action to verify that the change is valid.

For Codefresh CI, a KICS pipeline step is already available in the steps marketplace. You can therefore insert KICS anywhere in a Codefresh pipeline and use it to verify any supported IaC file.

Once the security scan is complete, you can further copy/upload the report to any supported storage provider of your choice, or use an intermediate format (e.g., json) to further process the results.

You can also apply the infrastructure files themselves directly via Codefresh pipelines. Codefresh has built-in support for Kubernetes/Helm manifests and can easily use any other IaC tool such as Terraform for creating a complete pipeline that both checks and applies Infrastructure as Code files.

Running KICS using the Codefresh GitOps platform

You can use KICS from the classic Codefresh CI platform as we saw in the previous section. There is also upcoming integration for using KICS in the new Codefresh Software Delivery Platform that is specifically created for GitOps deployments and is powered by the Argo Project. Adopting GitOps is a natural extension of Infrastructure as Code and the new integration will soon appear in the Codefresh Argo Hub. 

With KICS and Codefresh, developers and AppSec team can improve the security of their IaC to reduce risk and increase confidence of secure IaC. In fact, over 650K people have downloaded KICS as of date.

IaC (Infrastructure as Code) scanning as part of your software development life cycle is step one, and now we are taking scanning to the next phase. Besides scanning your IaC files, we can now connect and scan the deployed production environments to help identify any security misconfigurations in those environments. Whether those misconfigurations come from your IaC files, manual resource provisions and changes, or resources not being up to date with current versions or security features, KICS by Checkmarx can now help solve many of these issues.

In order to help developers, DevOps, and security teams with the challenge around IaC concepts such as managing cloud resources configurations, ensuring they are aligned across all environments, while keeping up with security best practices, an organization’s policies, and mitigating risks, we introduce KICS 1.5 release.

This release enables organizations to extract cloud resources configurations from runtime environments on AWS by leveraging Terraformer capabilities. Then organizations can construct the IaC files which reflects the runtime configuration, and scan them automatically with KICS, in order to get the actual security posture as seen in the scan report, which highlights a list of vulnerabilities and misconfigurations.

By using this new capability, developers, DevOps, and security teams can now scan live production environments and get an overview of their cloud security posture. In addition, manually comparing these results with the IaC pipeline scanning can help identify any cloud configuration drift.

According to Ori Bendet, Vice President of Product Management, Checkmarx, “With this new capability we are securing cloud infrastructure a step further. Companies can now scan their IaC pipelines together with their live environments and getting a better understanding of their cloud security posture.”

While this is a major step forward of automatically comparing security findings and misconfigurations between the cloud infrastructure’s different environments, and mitigating the risks as soon as they occur, we are planning to empower developers, DevOps, and security teams even further. Soon we’ll be supporting other Cloud providers infrastructure scanning (such as Azure, GCP, etc.) and also delivering an enhanced drift detection tool called “Driffty”, which will complement KICS capabilities and provide more actionable insights on top of it. So, stay tuned to what’s coming next!

But modern applications also present some steep challenges, not least in the realm of security. In order to thrive in the modern development landscape, developers and AppSec pros alike must be sure that their security skills can address the variety of threats that teams face today – a time when cyberattacks are growing steadily in frequency and scope.

Here’s a list of four essential security skills that anyone involved in modern application development should possess.

IaC Security

Infrastructure-as-Code (or IaC) tools have become an essential part of many modern application development workflows. Using IaC, teams can automatically provision large-scale software environments, which maximizes scalability and minimizes the risk of configuration mistakes due to human error.

But the downside of IaC is that, if the configurations applied using IaC templates contain security issues, those issues will be proliferated across your entire environment. And in most cases, the IaC tools themselves do nothing to alert you to potential security issues.

That’s why developers and AppSec teams must learn to follow security best practices when configuring IaC templates, such as:

• Secure your secrets: Don’t hard-code passwords or other secrets into IaC templates. Store them in an external secrets manager instead.
• Modularity: Keep IaC templates short and modular. Trying to cram too much configuration into a single template increases the risk of making a mistake.
• Use default settings with care: Don’t blindly trust default IaC settings. Make sure you tailor templates to your environment.

Just as important, teams should use IaC scanning tools to validate their IaC configurations prior to applying them. IaC scanners automatically check IaC templates for misconfigurations that could create security issues.

Open Source Security Risks

There are many excellent reasons for modern development teams to leverage third-party open source code. Open source saves time because it allows you to reuse code that someone already wrote rather than having to write it yourself from scratch. It is also often easy to customize. And it’s usually free of cost, which is never a bad thing.

Yet open source also poses some significant security risks when you incorporate it into your applications. You can’t guarantee that third-party open source developers adhere to the same security standards that you do when they write their code.

For that reason, it’s critical to know where in your application you incorporate open source code, and also to scan that code to identify known vulnerabilities within it.

Container Security

Modern applications are often deployed using containers. Because containers – and the orchestration platforms used to manage them (like Kubernetes) – add another layer of infrastructure and complexity to your software stack, they create a variety of potential security risks that would not be present if you were deploying applications directly on a host OS, without having a container runtime and orchestrator in the equation.

Modern developers and AppSec teams need to know what these risks are and take steps to address them. A full discussion of container security is beyond the scope of this article, but basic concepts include:

• Image security: Securing container images by ensuring that any external components on which they depend are secure, as well as using a container image scanner to check for vulnerabilities.
• Configuration security: Scanning the configuration files that are used to deploy and orchestrate containers. Like IaC templates, these files can contain configuration mistakes that enable security breaches.
• Runtime security monitoring: Using monitoring tools that can collect and analyze data from across complex containerized environments (which means collecting data from various containers, from all of the operating systems running within the cluster of servers that hosts your containers, and from the orchestration platform) to detect signs of breaches at runtime.

Microservices Security Risks

Microservices have become massively popular because they make it easy to build agile, scalable applications that lack a single point of failure, among other benefits.

But microservices also significantly increase the complexity of application architectures, which in turn increases the risks of security issues. Because microservices rely on the network to communicate with each other, there is a higher risk of sensitive data exposure. Insecure authentication and authorization controls between microservices could enable a breach to spread from one microservice to an entire app. Security problems with the tools used to help manage microservices (like service meshes) create another set of security risks to manage.

As with container security (which, by the way, is a closely related topic, because microservices are often deployed using containers), there is more to say about microservices security than we can fit into this article. But some core microservices security best practices for developers and AppSec teams to follow include:

• Microservices isolation: When designing your microservices architecture, strive to isolate each microservice as much as possible. Allow interactions between services only where strictly necessary.
• Authentication and authorization: Always require authentication and authorization for microservices to communicate with each other.
• Network isolation: Isolate the internal networks that microservices use from the public Internet, and never expose a microservice directly to the Internet unless it needs to be.

Conclusion: Modern Application Development Requires Modern Application Security

Most of the security challenges discussed above simply didn’t exist ten years ago. Back then, no one was provisioning hundreds of servers using IaC templates or deploying applications with highly complex architectures based on microservices and containers.

But those practices are the norm for modern application development. Developers and AppSec teams must respond by ensuring that they are able to leverage the tools and skills necessary to meet the modern security risks that go hand-in-hand with modern application development.

Chris Tozzi has worked as a journalist and Linux systems administrator. He has particular interests in open source, agile infrastructure, and networking. He is Senior Editor of content and a DevOps Analyst at Fixate IO. His latest book, For Fun and Profit: A History of the Free and Open Source Software Revolution, was published in 2017.

Click here to learn more about security in the context of Modern Application Development

“If everything seems under control, you’re not going fast enough.”

With the recent rise in cloud-native technologies, everything is going faster than ever. Development cycles are shorter than before, and teams are deploying to production continuously. Business demands and time-to-market are the main drivers in the need for speed, and as development teams try to keep up, the risks are much higher since a simple change can reach your entire customer base within minutes.

One of those cloud-native technologies is Infrastructure-as-Code (IaC) which automates the entire process of provisioning and deploying your infrastructure at the speed of DevOps. Beside the known benefits, this presents major risks to your applications and underlying infrastructure. It means that a single change in your IaC will reach production in a matter of minutes and can expose you to new attack vectors as well.

Based on recent research, which was done by analyzing vast number of KICS scans, here are the top IaC misconfigurations you should be aware of.

Top 5 Misconfigurations

1. Open ports – open TCP/UDP ports remain the top misconfiguration to date. Those include HTTP ports, SSH ports, ELB ports, or any other unnecessary ports. The best example to give here is SSH (port 22), which is usually used for remote debugging and is notoriously known for being left open for no good reason. Probing through open ports is probably the first step of every attacker’s TTPs. We also know that attackers use bots to scan for open ports, and once they find an open one, they simply brute force the password and often gain access to servers and other devices. Make sure you leave unnecessary ports closed, or have a good reason for why they may be open.
2. Excessive permissions – as previously written in this blog, providing a cloud resource with the wrong permissions can create the attack surface attackers are hoping for. Configuring your S3 bucket with read permissions, attackers can probe into the bucket looking for unprotected content and gain access to private information. Make sure you understand what least-privilege permissions your cloud resources need, and don’t leave anything to chance.
3. Lack of proper definitions – this affects observability (e.g., lack of proper logging), encryption (e.g., S3 objects without server-side encryption), or anything in between. Make sure you understand which resource requires which property, and make sure they are configured correctly in all cases.
4. Hard-coded secrets (in your IaC) – while not limited to IaC only, this remains a top challenge for all code (application source code as well). Once exposed, attackers can leverage the keys to obtain sensitive information, shut down services, or create whatever resources they need.
5. IaC security drift – we have all been there, we work perfectly through the process, our pipelines are all green, then something happens in production, and we must make a “small” change. Those small changes can have a huge risk on your environment, and you should not make those directly but through code. Using drift detection tools (e.g., Terrarfomer or Driffty), you can get a static file which represents your current production environment, then scan it with KICS to make sure you didn’t introduce any new risk.

Leveraging Infrastructure-as-Code is a critical part of achieving true infrastructure agility, but you should be aware of all the risks. Running fast is important, but don’t become blind to what may surface from errors and omissions. Be aware of the potential misconfigurations listed above and make sure you tackle them from the very beginning.

If you want to automate your IaC security scanning – you can easily integrate KICS into your pipeline and make sure you are appropriately managing your IaC risks.

More about KICS

KICS finds security vulnerabilities, compliance issues, and infrastructure misconfigurations in popular IaC solutions and OpenAPI 3.0 specifications. KICS is open source and always will be. Both the scanning engine and the security queries are clear and open to the software development community. With 2000+ fully customizable and adjustable heuristic rules, or queries, KICS can be easily edited, extended, and added to. What’s more, our robust but simple architecture allows for support of new IaC solutions.

Almost 500,000 people are already taking advantage of KICS. Download KICS for free here and start securing your IaC today!

According to their website, “The Center for Internet Security, Inc. (CIS®) makes the connected world a safer place for people, businesses, and governments through our core competencies of collaboration and innovation.  We are a community-driven nonprofit, responsible for the CIS Controls® and CIS Benchmarks, globally recognized best practices for securing IT systems and data.”

In our connected world, the need for collaboration, innovation, and best practices are vastly needed. In fact, CIS has four world-renowned, best practices and expert communities.

Going a little deeper into one particular area of interest, “CIS SecureSuite Membership provides integrated cybersecurity tools and resources to organizations of every size. Security IT teams can automate configuration assessments, conduct remote scans, implement security best practices, and more.”

Why is CIS Important to Checkmarx and the Developer Community?

KICS is an open-source project backed by Checkmarx that is purposely designed to scan infrastructure as code (IaC). KICS has had an incredibly successful launch with over 450K downloads as of date!

More importantly, Checkmarx is a CIS SecureSuite® Product Vendor Member, and our KICS solution has recently been awarded the following certifications from CIS:

KICS 1.4.4 (version)

• CIS Amazon Web Services Foundations Benchmark v1.4.0, Level 1
• CIS Amazon Web Services Foundations Benchmark v1.4.0, Level 2

We are extremely proud to have been awarded these certifications, and achieving Level 2 certification is a very notable achievement. Level 2 means that a technology provides “measurable defense in depth” protection.

From a static tool perspective, KICS performed exceptionally well in all evaluation criteria. Although some may say that not being a dynamic solution (testing code while running) is a limitation, KICS scans code much earlier than any dynamic testing solution ever could. KICS gets results and solves issues in IaC way earlier in the pipeline – from the first line of code written – long before the first docker, first container, or first asset were even provisioned. This is a huge differentiator in comparison to dynamic testing solutions.

According to Ori Bendet, Head of Product Management at Checkmarx, who helped spearhead the KICS project, “KICS supports the philosophy of shifting left by testing and securing code as early in the cycle as possible. Developers carry so much responsibility these days—from source code to integrating open source libraries, to containers and Infrastructure-as-Code. Each of these tasks possess its own security risks. From the first line of code developers write, Checkmarx delivers SAST, SCA, and KICS to shore up security on static code, open source code, and infrastructure as code. Combing these solutions, and using them early and often, organizations can feel confident that the code they deploy is secure.”

“As of yet, KICS is the only, completely open source project that has achieved any CIS Certification”, says Erez Yalon, Head of Security Research at Checkmarx. “This serves as a testament to what the open source community is capable of achieving. Checkmarx is very happy to have initiated the project, then opening it up to the community for their contribution. Our list of contributors should receive many thanks for what they have accomplished.”

Want to Know More About KICS?

Just like SAST that scans application source code, finding vulnerabilities and security issues within, KICS scans infrastructure code to finds issues that may lead to potential vulnerabilities as well. Since KICS is open source, you don’t need any licenses to use it. You can just go to the repository or download it from Docker Hub, and you can have it up and running in as little as a few minutes, to start scanning your infrastructure code. Also, KICS integrates into a wide variety of CI/CD solutions.

KICS finds security vulnerabilities, compliance issues, and infrastructure misconfigurations in popular IaC solutions and OpenAPI 3.0 specifications. KICS is open source and always will be. Both the scanning engine and the security queries are clear and open to the software development community. With 2000+ fully customizable and adjustable heuristic rules, or queries, KICS can be easily edited, extended, and added to. What’s more, our robust but simple architecture allows for support of new IaC solutions.

Download KICS for free here and start securing your IaC today!

However, the devil is in the details and trying to implement those tools in real life often comes with risks. In this article we explain those risks with using IaC, coming from a developer’s point of view.

Biggest Risks of IaC

Steep learning curve

To start with, using IaC tools without taking the dedicated time to learn some of their quirks and limitations can become not just an inconvenience, but a serious problem.

Many of the most prevalent IaC tools like – Terraform and CloudFormation – are incredibly simple to start. But they become very complicated as your requirements change over time. For example, trying to utilize custom resources in CloudFormation requires some insight into how CloudFormation works under the hood. Failure to delve into the inner details will put your organization at increased risk of configuration drift, pushing the wrong infrastructure components or obtaining a system in an incomplete state.

Another example that requires some deep insight of how Terraform works is with Terraform Imports. The official page mentions in the warning box that:

“If you import the same object multiple times, Terraform may exhibit unwanted behavior“

However, you will need to delve into the details in order to understand the nature of this unwanted behavior. What does it really mean? Does it create configuration drift? Does it break the local tfstate file? How can you prevent importing the same object multiple times? All of those questions need time and dedication to answer. As a developer, you should reserve that time as part of the process of learning the tool while using it for real projects.

Human mistakes

Some IaC tools have a distinct set of phases that you need to perform in a specific order. For example, in Terraform we have the following steps:

1. terraform plan : Creates an execution plan for what terraform will perform against the infrastructure.
2. terraform apply : Applies the plan.

Failure to perform a plan review before using apply can result in destructive changes. This is because a visual inspection beforehand gives you one more chance to review the changes before applying. The caveat here is that, by default, there is no requirement to follow the order. Directly applying the changes, skipping the first step, could lead to unfortunate mistakes.

The repercussions of missing a destructive change can be excruciatingly painful. It is recommended that you invest in establishing automated protections to apply changes to infrastructure. For example, instead of manually reviewing terraform plan outputs (which could be lengthy), you should invest in PR (pull request) automation tools like Atlantis to help in discovering any unintentional destructive changes early.

Configuration drifts

Terraform and other tools can help in maintaining infrastructure components and associated attributes, as long as they are managed solely by them. For example, Terraform cannot detect any drift of resources if you have applied while using other tools like Chef or Puppet. This could be a major problem for organizations still working on a variety of IaC tools that are unaware of each other or overlap their body of work.

Scanning for drift helps with figuring out those deviations between the IaC tool and the real infrastructure. Because each case is different, you will find there are virtually no public or private services that do that for you accurately. The best option for managing configuration drift for your organization is to make sure there is no overlap between the various IaC tools; any changes to the infrastructure are monitored by one IaC tool; and some sort of reporting and health checking are integrated. External checks can also sometimes help to verify that.

Difficulty protecting sensitive data and exposing ports

Although Terraform and CloudFormation can provision infrastructure components, there are some questions that need answering. For example, how would you know during the process if it leaked sensitive data? How would you know if the S3 bucket it manages in fact contains the security profiles you specified? Are you using a provider that leaks sensitive data to stdout? Did you unexpectedly open a port to the internet?  

These are only a subset of questions you need to answer when delegating your Infrastructure management to IaC tools. It’s easier to make a mistake and expose resources to the public web than the opposite, so there are a lot of things at stake here.

[In fact, in an analysis done by Checkmarx in August 2021, one of the most common IaC misconfigurations is having HTTP port 80 and ELB ports being left open to the public.]

How Should Developers Detect and Mitigate the Most Common IaC Risks?

As mentioned, most of the common risks can be mitigated by adhering to some common security best practices so it’s not all doom and gloom. Here is what you can start practicing:

• Spend some time with the tools: Spend time to fully understand how each tool works: its quirks, its open issues and its best practices. Participate in meetups and subscribe to events so you can learn from other industry experts. This will give you an advantage when trying to figure out how to perform tasks – simple and advanced – without compromising the security posture.
• Establish common engineering processes and best practices: Practice peer code reviews, CI/CD checks, linting, and verification. This can reduce the number of common accidents and mistakes that happen when you rush things.
• Use purpose-built IaC security tools: Look around for purpose-built tools like Checkmarx KICS (Keeping Infrastructure as Code Secure) that help you establish a secure and efficient infrastructure-as-code pipeline. The benefit of this tool is that you can configure it to match your organization’s policies due to its great extensibility and cloud provider coverage.

[If you are looking to get a quick look and better understanding on your current state, you can also quickly upload your IaC into Checkmarx new KICSaaS and get immediate results without having to download anything. Give it a try at: https://kics.checkmarx.net]

How and Where Can Developers and Security Teams Learn More About the Risks?

First and foremost, you can learn more about the risks of IaC by asking local IaC experts or official communities about some of their experiences with IaC. You may find that many of the issues they encounter prepare you for what to expect and what to look out for.

Furthermore, you should subscribe to reputable email lists and blogs from vendors that specialize in those areas, and offer tailored solutions like KICS for tackling most of the problems explored in this article.

Lastly, you should perform your own investigation to assess the pros and cons of each tool based on your own requirements and success criteria. The one-size-fits-all approach isn’t suitable for all lines of business. By performing all the necessary steps, you can hopefully mitigate most of the critical risks of using IaC tools.

—

Theo Despoudis is a Senior Software Engineer, a consultant and an experienced mentor. He has a keen interest in Open Source Architectures, Cloud Computing, best practices and functional programming. He occasionally blogs on several publishing platforms and enjoys creating projects from inspiration. Follow him on Twitter @nerdokto. He can be contacted via http://www.techway.io/.

Download our Ultimate Guide to SCA here.