{"id":4651,"date":"2026-07-24T06:05:19","date_gmt":"2026-07-24T06:05:19","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/07\/24\/building-soc-2-compliant-ci-cd-pipelines-on-aws-with-github-actions\/"},"modified":"2026-07-24T06:05:19","modified_gmt":"2026-07-24T06:05:19","slug":"building-soc-2-compliant-ci-cd-pipelines-on-aws-with-github-actions","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/07\/24\/building-soc-2-compliant-ci-cd-pipelines-on-aws-with-github-actions\/","title":{"rendered":"Building SOC 2 Compliant CI\/CD Pipelines on AWS with GitHub Actions"},"content":{"rendered":"
\"\"<\/div>\n

\"\"<\/p>\n

CI\/CD pipelines make developers\u2019 lives easier<\/a> and let them ship changes to end users faster. However, they are also part of compliance frameworks such as SOC 2, which require careful design to satisfy specific controls.<\/p>\n

AWS Account Architecture<\/h3>\n

You don\u2019t want to host all your environments, such as staging and prod, in the same AWS account but rather use a multi-account AWS architecture.<\/p>\n

Each of your environments \u2014 dev, staging, UAT, prod \u2014 should live in its own separate AWS account, rather than having all of them share a single account. This way, you can have clean logical access controls (CC6.1).<\/p>\n

Once each environment has its own account, a natural question follows: Where should your ECR repository live? Should you host one in each environment account or centralize it in a single account that all environments pull images from?<\/p>\n

ECR Repository Architecture<\/h3>\n

You could host your ECR repository in the prod environment account, but ideally, you should create a separate AWS account for shared tooling and host your ECR repository there. Your pipeline should only have push access to that repository, scoped to the common account.<\/p>\n

Each environment account (dev, staging and prod) then needs cross-account permissions to pull (not push) images from that shared repository. In the common account, create an IAM role that authenticates via OIDC and can push to the relevant ECR repositories. This role doesn\u2019t need pull access.<\/p>\n

An example permissions policy for that role is as follows:<\/p>\n

{<\/code> \"Version\": \"2012-10-17\",<\/code> \"Statement\": [<\/code> {<\/code> \"Sid\": \"AllowECRAuth\",<\/code> \"Effect\": \"Allow\",<\/code> \"Action\": \"ecr:GetAuthorizationToken\",<\/code> \"Resource\": \"*\"<\/code> },<\/code> {<\/code> \"Sid\": \"AllowPushToScopedRepos\",<\/code> \"Effect\": \"Allow\",<\/code> \"Action\": [<\/code> \"ecr:BatchCheckLayerAvailability\",<\/code> \"ecr:PutImage\",<\/code> \"ecr:InitiateLayerUpload\",<\/code> \"ecr:UploadLayerPart\",<\/code> \"ecr:CompleteLayerUpload\"<\/code> ],<\/code> \"Resource\": [<\/code> \"arn:aws:ecr:<REGION>:<COMMON_ACCOUNT_ID>:repository\/myapp-*\"<\/code> ]<\/code> }<\/code> ]<\/code>}<\/code><\/p>\n

ecr:GetAuthorizationToken has to stay scoped to all resources since AWS doesn\u2019t support restricting that specific action to a repository ARN. It\u2019s how the ECR login token is issued. Everything else is locked to the specific repository naming pattern, not a bare wildcard.<\/p>\n

The trust policy below is what actually enforces who can assume this role. It defines exactly which GitHub repository and branch is permitted to authenticate via OIDC. Without this scoping, any workflow in your GitHub organization could potentially assume the role.<\/p>\n

{<\/code> \"Version\": \"2012-10-17\",<\/code> \"Statement\": [<\/code> {<\/code> \"Effect\": \"Allow\",<\/code> \"Principal\": {<\/code> \"Federated\": \"arn:aws:iam::<COMMON_ACCOUNT_ID>:oidc-provider\/token.actions.githubusercontent.com\"<\/code> },<\/code> \"Action\": \"sts:AssumeRoleWithWebIdentity\",<\/code> \"Condition\": {<\/code> \"StringEquals\": {<\/code> \"token.actions.githubusercontent.com:aud\": \"sts.amazonaws.com\"<\/code> },<\/code> \"StringLike\": {<\/code> \"token.actions.githubusercontent.com:sub\": \"repo:<GITHUB_ORG>\/<GITHUB_REPO>:ref:refs\/heads\/main\"<\/code> }<\/code> }<\/code> }<\/code> ]<\/code>}<\/code><\/p>\n

The sub condition is what actually locks this down. It ensures that only workflows running against the main branch of this specific repository can assume the role. You can modify this role later or create new ones as you add more GitHub repositories and their corresponding ECR repositories.<\/p>\n

Last, make sure \u2018scan on push\u2019 is enabled on your ECR repository. This ensures that every image is automatically scanned for known vulnerabilities the moment it\u2019s pushed, rather than on a periodic schedule. It\u2019s a direct piece of evidence for CC7.1 (vulnerability management).<\/p>\n

ECR Life Cycle Policies<\/h3>\n

Set up life cycle policies so your ECR repository doesn\u2019t grow indefinitely and rack up storage costs. Don\u2019t use one blanket rule though, since untagged images, dev builds and promoted releases have different retention needs.<\/p>\n

Expire untagged images within a few days; they have no ongoing value. For dev-tagged images, size the retention count to your actual dev cycle rather than guessing a fixed time window. If your team iterates through many builds before settling on one to promote, keep a larger count (500\u20131,000); if your dev cycles are short, a smaller count (100\u2013200) is fine. For staging- and prod-tagged images, keep the last 100\u2013200 releases regardless of age, since these serve as your audit trail.<\/p>\n

{<\/code> \"rules\": [<\/code> {<\/code> \"rulePriority\": 1,<\/code> \"selection\": {<\/code> \"tagStatus\": \"untagged\",<\/code> \"countType\": \"sinceImagePushed\",<\/code> \"countUnit\": \"days\",<\/code> \"countNumber\": 3<\/code> },<\/code> \"action\": { \"type\": \"expire\" }<\/code> },<\/code> {<\/code> \"rulePriority\": 2,<\/code> \"selection\": {<\/code> \"tagStatus\": \"tagged\",<\/code> \"tagPrefixList\": [\"dev-\"],<\/code> \"countType\": \"imageCountMoreThan\",<\/code> \"countNumber\": 200<\/code> },<\/code> \"action\": { \"type\": \"expire\" }<\/code> },<\/code> {<\/code> \"rulePriority\": 3,<\/code> \"selection\": {<\/code> \"tagStatus\": \"tagged\",<\/code> \"tagPatternList\": [\"*.*.*\"],<\/code> \"countType\": \"imageCountMoreThan\",<\/code> \"countNumber\": 200<\/code> },<\/code> \"action\": { \"type\": \"expire\" }<\/code> }<\/code> ]<\/code>}<\/code><\/p>\n

ECR evaluates rules in priority order, and each image is expired by the first rule that matches it, so the order and tag prefixes matter. Adjust the dev- prefix and the numbers to match your own tagging convention and release cadence.<\/p>\n

Now you can design your pipeline based on how your team works. Here\u2019s one example, assuming you have dev, staging and prod environments.<\/p>\n

CI\/CD Pipeline Architecture Example<\/h3>\n

When a pull request merges into main, the pipeline deploys to dev. Use image tagging, for example semver, so each dev build gets a dev- prefix, a patch version and the last seven characters of the commit SHA. Dev image tags in ECR would look like this:<\/p>\n

dev-0.2.1-a3f9c2e<\/code>dev-0.2.2-8d4b17f<\/code><\/p>\n

Each of these tags should also be tagged in GitHub so you can show an auditor exactly which commit was running in a given environment at a given time.<\/p>\n

Once you\u2019re happy with a dev version and want to promote it to staging, use a manual workflow trigger that retags that specific dev image, passing the target minor version as a parameter (no commit SHA needed). For example, dev-0.2.2-8d4b17f gets a second tag, 0.3.0. This is the same image with two tags, not a new build, which is the point: You\u2019re promoting the exact artifact that was tested in dev, not rebuilding it.<\/p>\n

If you find that dev, staging and prod need genuinely different images, that\u2019s usually a sign of a design problem elsewhere in the pipeline. The better fix is to parameterize whatever differs between environments (config, environment variables or feature flags) rather than building separate images per environment.<\/p>\n

Say staging runs integration tests, load tests and whatever else is part of your pipeline, and you\u2019re ready to promote to prod. Use another manual workflow trigger, ideally with a required approval step that retags the same image with a version bump. For example, 0.3.0 gets a third tag, 1.0.0. At this point, the same image carries three tags: dev-0.2.2-8d4b17f, 0.3.0 and 1.0.0.<\/p>\n

Now you\u2019re running the same artifact in prod that was tested in dev and staging. It\u2019s also traceable back to the exact code version running on GitHub, satisfying CC8.1 (change management).<\/p>\n

Conclusion<\/h3>\n

This covers a common CI\/CD pattern, not a one-size-fits-all blueprint. Your account structure, tagging scheme and life cycle rules should reflect how your team actually works. Review this against your own SOC 2 scope and controls and adjust it where your workflow genuinely differs.<\/p>\n

Keep in mind that this is only the CI\/CD part of SOC 2 on AWS. Achieving complete SOC 2 compliance on AWS<\/a> requires considering more details such as GuardDuty, Security hub and more tools.<\/p>\n

Read More<\/a><\/p>\n

\u200b<\/p>","protected":false},"excerpt":{"rendered":"

CI\/CD pipelines make developers\u2019 lives easier and let them ship changes to end users faster. However, they are also part […]<\/p>\n","protected":false},"author":1,"featured_media":4652,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[5],"tags":[],"class_list":["post-4651","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops"],"_links":{"self":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/4651","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/comments?post=4651"}],"version-history":[{"count":0,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/4651\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media\/4652"}],"wp:attachment":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media?parent=4651"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/categories?post=4651"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/tags?post=4651"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}