Skip to content
Access & control

Source analysis and AWS deployment are separate steps.

Know what you share for analysis, what access a deployment needs and where your approval fits in the workflow.

Source code is an analysis input

saasups analyzes the repository or source archive provided to it. That source can contain application code, dependency manifests and configuration. Review the material you share and the analysis configuration for your project.

Analysis does not authorize deployment

Running an assessment is separate from authorizing AWS resource changes. Provisioning requires an AWS connection with the necessary permissions and a reviewed deployment plan.

Deployment uses a role you create, not keys you hand over

You launch a CloudFormation stack in your own account that creates an IAM role trusting the saasups provisioner, gated by a per-connection ExternalId. saasups assumes that role for short-lived STS credentials and stores no long-lived keys.

  • CloudFormation-created IAM role gated by an ExternalId
  • Short-lived STS credentials; no long-lived keys stored
  • Read-only by default; read-write is a separate onboarding

Inspect the plan before applying it

The supported deployment workflow includes plan preview, blocker review and an approval step. Generated infrastructure and pipeline files make the proposed work inspectable.

  • Plan preview and blocker review before approval
  • Approval recorded by a named operator against the plan fingerprint
  • Apply and destroy each write an audit row

Every account signs in with a second factor

Two-factor authentication is mandatory for every account on the operator console and the product: an authenticator app (TOTP) plus backup codes, with no opt-out. An operator-assisted reset exists for a lost device, and it writes an audit row.

Keep application code and deployment changes distinct

The current workflow generates deployment artifacts instead of rewriting the original application source. Supported compatibility adjustments happen in the delivery layer; additional application changes may still be required.

Public demos have public results

The public repository assessment flow asks for explicit consent to publish the resulting report in the gallery. Private source and report requirements should be discussed through the technical demo flow.

Discuss a private application

Review project-specific data handling

Before sharing private source, confirm the configured analysis providers, processing location, retention requirements and access model with the team. Request supporting security documentation for your evaluation.

Contact the team
Start with your application

Let’s map your next step on AWS.

Discuss your codebase, target architecture and delivery requirements in a technical demo.

Have an open-source application? Request a public repo assessment.

Requests are reviewed before analysis. Public reports are published with your consent.