Alye / Resources / Blog
Blog

Introducing Alye Security: fix the few findings that matter

Why we added cloud and code security to Alye, how it ranks issues by what an attacker could reach, and why it only ever needs read-only access.

By the Alye team5 min readProductSecurity

The first scan of a cloud account usually returns hundreds of findings. Sorted by severity, a public test bucket with nothing in it sits next to a production database the internet can reach. Most teams either try to fix everything and stall, or stop reading the list. We built Alye Security to answer a smaller question first: can someone get from the internet to your data, and what is the one change that stops them?

Why a second module

Alye started with LLM observability: what every model call costs and when it fails. The teams using it kept asking the same thing about their cloud that they asked about their AI spend: of everything going on, what actually needs my attention today? The answer has the same shape. Record everything, add the context that changes the ranking, and put the few things that matter at the top.

What it does

  • Maps your cloud the way an attacker would. What faces the internet, which role each workload runs as, and which data that role can reach, across AWS and Google Cloud accounts.
  • Finds attack paths to sensitive data. You mark data stores with tags such as data-class=pii; Alye follows every route from the internet to them and shows each route's weakest link.
  • Ranks Issues by reach, not just severity. A vulnerable package on an exposed production server comes before the same package in a sandbox. Deadlines follow the risk.
  • Writes the fix for your resources. AWS CLI, Terraform, CloudFormation or console steps, filled in with your resource names and IDs. For code, it opens pull requests for dependency and base-image upgrades that you review and merge.
  • Checks the fix worked. The daily rescan confirms the change and closes the Issue by itself, and reopens it if the change is reverted.

Read-only, by design

Connecting AWS creates one IAM role in your account with AWS's SecurityAudit and ViewOnlyAccess policies, which only Alye can assume and only with your organization's external ID. On Google Cloud it is the Viewer and Security Reviewer roles through federation. Neither can create, change or delete anything, and neither reads the contents of your buckets, databases or secrets. Every call shows up in your own CloudTrail or Cloud Audit Logs. You can remove access at any time by deleting the role.

If you want Alye to apply cloud fixes for you, you create a separate fix role, and it only makes changes someone in your organization approves. Most teams start without it and apply fixes in their own pipeline.

What it deliberately doesn't do

Alye Security isn't a penetration test and doesn't send traffic to your workloads. It doesn't install agents, doesn't read your data, and never pushes to your default branch. It finds known vulnerabilities and misconfigurations in what it can see, ranks them, and helps you close them.

Try it

Connecting an account takes a few minutes and the first ranked list arrives in about fifteen. Alye Security is priced for what you connect: book a demo and we'll walk through it on your own account, or read how attack path analysis works first.

See this in your own cloud. Alye Security connects read-only and ranks every issue by what an attacker could reach.

Book a demo

Related on Alye

More from the blog

Get started

Ready to put Alye on duty?

First trace right away. First ranked scan in about fifteen minutes.

Start free Read the docs