Will JavaScript type annotations kill TypeScript?
The creators of Svelte and Turbo 8 both dropped TS recently saying that "it's not worth it".
Yes: If JavaScript gets type annotations then there's no reason for TypeScript to exist.
No: TypeScript remains the best language for structuring large enterprise applications.
TBD: The existing user base and its corpensource owner means that TypeScript isn’t likely to reach EOL without a putting up a fight.
I hope they both die. I mean, if you really need strong types in the browser then you could leverage WASM and use a real programming language.
I don’t know and I don’t care.
Security / Software Development

Top 5 Security Risks for Infrastructure-as-Code

Infrastructure as Code (IaC) technology is increasingly being adopted by organizations to provide capabilities to rapidly provision and deploy cloud environments.
Apr 28th, 2020 7:37am by
Featued image for: Top 5 Security Risks for Infrastructure-as-Code

Accurics sponsored this post.

Piyush Sharrma
Piyush is co-founder and chief technology officer at Accurics. He is a technologist, entrepreneur, and engineering leader with almost 20 years of experience building large-scale IaaS, endpoint, and data center security products. During his career, he has been an entrepreneur and co-founded multiple technology startups.

Infrastructure as Code (IaC) technology is increasingly being adopted by organizations to provide capabilities to rapidly provision and deploy cloud environments. Examples of IaC technologies include Terraform, AWS Cloud Formation templates, Azure Resource Manager templates, Chef, Puppet, Red Hat Ansible, Helm Charts, Kubernetes YML files, and OpenFaaS YML.

With the power of IaC comes the responsibility of managing security risks, which can be introduced if best practices are not followed. Insecure IaCs result in insecure cloud environments that could ultimately lead to compliance violations and data breaches in the cloud. According to the most recent Verizon Data Breach Investigation Report, cloud misconfigurations was one of the top reasons for incidents and breaches.

So what are the top security risks that are introduced due to insecure usage of IaC? In this post, we will take a look at the top five and follow up with the remaining in a subsequent article.

1. Network Exposures

Insecure IaC configurations can expand the attack surface, which enables reconnaissance, enumeration, and sometimes even the delivery of cyberattacks to a cloud environment. Configuring open Security Groups, publicly accessible cloud storage services, public ssh access, and databases that are accessible from the internet, are examples of common IaC misconfigurations that increase the attack surface in the cloud. Below is a sample IaC snippet that highlights code with these issues.

Tip: Perform static security analysis of IaC and eliminate risks early in the cloud deployment lifecycle. Detecting and fixing these issues early is highly cost-effective and reduces your residual risks.

2. Vulnerabilities

Today, IaC templates are used to provision compute and containerized instances by including base images stored in trusted registries. This presents an opportunity to detect and address any known vulnerabilities in such base images early and dramatically reduce the cost of remediation. The following examples illustrate the use of vulnerable AMI and Docker images.

Tip: Perform vulnerability assessment of images referred to within IaC files and detect vulnerabilities early in the development lifecycle.

3. Unauthorized Privilege Escalations

Today, IaC is used to provision full-stack cloud environments that may include Kubernetes, containers, and microservices. Developers often use privileged accounts to provision cloud apps and other layers, which introduces risk of privilege escalation. If this risk is combined with hard-coded secrets and network exposures, a serious breach path is exposed to attackers.

Tip: Ensure least privileges principles are enforced in IaC and detect privilege creeps in IaC.

4. Configuration Drifts

While developers might be following IaC best practices, an urgent situation may force an operations team to make a configuration change directly in the production environment. This behavior breaks the immutability of cloud infrastructure which is based on the premise that infrastructure is never modified after it is deployed. If something needs to be updated, fixed, or modified in any way, new infrastructure has to be provisioned through code. More importantly, the configuration change may introduce risk which results in the posture of the cloud drifting from the secure posture defined through IaC before the infrastructure was provisioned.

Tip: Maintain immutability of infrastructure by monitoring for posture drifts between provisioned cloud infrastructure and IaC, and mitigate changes that introduce risks.

5. Ghost Resources

Tagging of cloud assets is a critical requirement to ensure compliance and governance. Untagged resources built using IaC result in ghost resources that can cause challenges in detecting, visualizing, and gaining observability within the actual cloud environment. The result is cloud posture drifts that can go undetected for long periods of time, as well as challenges in remediating risks. Aside from the security ramifications, untagged resources also make it extremely difficult to detect the impact on operations such as cost, maintenance, and reliability.

Read next: 5 More Security Risks for Infrastructure-as-Code

Feature image by PHOTOCREO Michal Bednarek via Shutterstock.

Group Created with Sketch.
TNS owner Insight Partners is an investor in: Docker.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.