Skip to content
Code To Cloud

We built this app. Is it secure, and is it built the right way?

Apps get built fast now, often with AI coding tools or a vendor. We review the code for security problems, and check how it's built, released and hosted against good engineering practice.

Last updated:

Who it's for, and who it isn't.

A good fit

  • You're about to launch an app, or a customer or investor is asking whether it's secure.
  • The app was built quickly, with AI coding tools or by a vendor, and nobody has reviewed it since.
  • You want to know whether a change can reach production without anyone checking it.

Probably not yet

  • You need a compliance audit or certification. This is an engineering assessment.
  • You can't share the source code. We need read access to the repository.

Score yourself in two minutes.

Answer for your own environment. You'll get a security score, a best-practice score and your gaps, each linked to the public framework it comes from.

Part 1 · Is it secure?

1. Has the code had a security review by someone other than the person, or AI tool, that wrote it?

2. Are dependencies scanned for known vulnerabilities on every build?

3. Are all secrets kept out of the code and its history, in a vault or secret store?

4. Are sign-in and permissions handled by a proven identity provider or library, not written from scratch?

Part 2 · Is it set up the right way?

5. Does every change to production go through a reviewed pull request?

6. Are builds and deployments run by a pipeline, never from someone's laptop?

7. Do your pipelines sign in to the cloud without long-lived secrets, for example with OIDC or a managed identity?

8. Are development and test environments separate from production, with no copies of production data?

0 of 8 answered

Is it secure?

  • Code review

    Automated scanning plus a review by an engineer of authentication, authorization, input handling and data protection, including code written with AI assistants.

  • Dependencies and supply chain

    Open source packages with known vulnerabilities, unmaintained libraries, and how builds are produced.

  • Secrets and configuration

    Keys, passwords and connection strings in code, history or pipelines, and insecure defaults.

Is it set up the right way?

  • Development governance

    Code review, branch rules and release approvals: whether a change can reach production without anyone checking it.

  • Hosting of the dev stack

    Where build agents, test environments and pipelines run, what they can reach, and how they authenticate to the cloud.

  • Secure development practice

    How the team builds software, checked against NIST's Secure Software Development Framework, so the next release is safer than this one.

Public frameworks, not our opinion.

Findings you can act on.

  • Written findings for security and for best practice, with the evidence behind each one.
  • A prioritized list of what to fix first, in the order to do it.
  • A working session where we walk your team through the findings.

From first call to findings.

  1. 01

    Discovery call

    Thirty minutes on what you run and what's worrying you.

  2. 02

    Scope agreed in writing

    We confirm what's in and out, and the fixed fee, before any work starts.

  3. 03

    Assessment

    We review security and best practice against the frameworks on this page.

  4. 04

    Readout and next step

    We walk through the findings. Fixing them with us is your choice.

Questions about the Application Security Assessment.

What is an Application Security Assessment?

A fixed-fee review of an application you built. On security, it covers the source code, dependencies and secrets. On best practice, it covers the controls on how changes reach production, how the development stack is hosted, and how the team builds software. You get written findings and a prioritized fix list.

Does it cover code written with AI coding tools?

Yes. AI-written code gets the same review as any other code, and we look closely at the problems it tends to introduce: hard-coded secrets, permissive defaults and outdated packages.

Is this the same as a security audit?

People often call it one. It is a security review of how your environment is configured and built, measured against the public frameworks named on this page. It is not a compliance audit or certification and makes no compliance, certification or data residency finding, though the findings can feed one.

Where do you work?

We're in the Calgary area and work with clients across Canada and the United States. The assessment is delivered remotely, on Mountain Time.

How much does it cost?

The Application Security Assessment is a fixed fee, scoped on a discovery call and agreed in writing before work starts. The fee depends on the size of what's in scope.

What access do you need?

We agree the access in the written scope. We ask for read-only access wherever it's enough, and time with the people who run the environment.

Who does the work?

Each engagement has its own lead from our team of employees and specialist contractors in cloud, AI and software engineering, with the team sized to the work. Leads make the day-to-day decisions, so nothing waits on one person. Kevin Evans, the founder and a Microsoft MVP for Azure, sets the technical standards we all build to. Everything is built in your own tenant and repositories, so your team owns and extends it.

What happens after the assessment?

You decide. Some teams fix the findings themselves. Some ask us to fix them with their team, as a project. Either is a normal outcome.

Ready to find out?

Book a discovery call. We'll scope the Application Security Assessment with you, or tell you if you don't need it yet.