Your Ci/Cd Pipeline Can Be Secure-Until Someone Finds The Secret You Left Behind
How GitHub Actions secrets and AWS S3 configuration drift can create a path to malware entering your software supply chain
Your developers may follow the right process. A developer creates a pull request. The code goes through review. Automated tests run. Security checks run. Someone approves the change. The pipeline deploys it. It looks controlled. But what happens if an attacker doesn’t need to go through that process? A leaked GitHub Actions credential, an overly permissive cloud identity, or an AWS S3 configuration that has quietly drifted away from your intended security settings can create another route into your development and deployment environment. And once an attacker gets the right level of access, the concern isn’t just stolen data. They may be able to influence what your pipeline builds or deploys. That can turn a cloud security problem into a software supply chain problem. The problem starts with the credentials your pipeline needs CI/CD pipelines need access to things. They may need to:
- Pull code and dependencies
- Build applications
- Push container images
- Access cloud resources
- Publish packages
- Deploy to production
- Upload or retrieve build artifacts
Those permissions are useful to your developers and automation. They’re also valuable to an attacker. GitHub Actions provides several ways to handle secrets and credentials, but mistakes can still happen. A secret can end up in a repository, workflow configuration, build log or another location where it shouldn’t be. Sometimes the problem isn’t even an obvious password sitting in a source file. It could be a cloud credential with more permissions than the workflow actually needs. The important question is therefore not simply: Do we have secrets in GitHub? It’s: If one of our CI/CD credentials were exposed, what could an attacker actually do with it? That is a much more useful security question. What happens when a CI/CD credential is compromised? Imagine an attacker obtains credentials associated with a GitHub Actions workflow. Those credentials may allow the workflow to interact with AWS or another part of your cloud environment. If the permissions are too broad, the attacker may gain access to resources that were never intended to be controlled by that workflow. Depending on the environment, that could include source code, build artifacts, deployment resources or storage. And this is where the risk becomes serious. Instead of trying to break through your production application directly, an attacker may look for a way to influence the process that produces or deploys your application. The security boundary has moved from your production server to your development pipeline. And then there’s S3 configuration drift AWS S3 is widely used for storing things such as build artifacts, application files, logs and other data. The problem isn’t that S3 is inherently insecure. The problem is configuration drift. Your security team may establish the correct access controls today.
Six months later, someone changes a bucket policy, modifies an IAM permission, changes an automation workflow or introduces a new deployment process. The environment has changed. But your original security assumptions haven’t. That difference is configuration drift. A bucket that was supposed to be private may become more accessible than intended. An identity that only needed limited access may gradually accumulate additional permissions. Individually, these changes might not look dramatic. Together, they can create an unexpected path through your environment. Why CI/CD and cloud security cannot be treated separately This is where things get interesting. Your GitHub Actions environment and your AWS environment may be managed by different teams. Developers manage workflows. Cloud engineers manage infrastructure. Security teams monitor both. But an attacker doesn’t care where your organizational boundaries are. They look for the connection. For example: GitHub Actions → IAM credentials → AWS → S3 → build/deployment process If one part of that chain is poorly protected, the security of the entire chain can be affected. That’s why securing the cloud while ignoring the CI/CD pipeline isn’t enough. And securing GitHub while allowing cloud permissions to grow unchecked isn’t enough either. The malware problem This is ultimately about more than configuration. Think about what your development team normally trusts. A pull request goes through review. Security checks run automatically. The build pipeline creates an artifact.
The artifact is deployed. Everyone assumes the process has provided some level of assurance. But what if an attacker finds a way to influence the build or deployment process without submitting an obvious malicious pull request? That creates a very different problem. The malware may not arrive through a traditional attack against your production server. It could potentially enter through the software delivery process itself. And once malicious code is packaged into something your organization normally trusts, detecting it can become considerably harder. Three questions I would ask your security team If your company relies heavily on GitHub Actions and AWS, I’d start with these:
1. What can our CI/CD credentials actually access? Don’t settle for knowing that the credentials are stored securely. Look at the permissions. If a workflow only needs to upload an artifact to one S3 bucket, why should it have permission to interact with dozens of other resources? Least privilege matters.
2. Would we know if our cloud configuration changed?
Your approved architecture is only useful if you can detect when the live environment moves away from it. Ask: Who gets notified when an S3 bucket policy, IAM permission or other security sensitive configuration changes? If the answer is unclear, you may have a visibility problem.
3. Can someone bypass the controls we rely on before deployment? Pull request approval is useful. Automated security scanning is useful. Branch protection is useful.
But you should also understand whether your credentials, workflows and deployment permissions could allow someone to circumvent those controls. Security controls are only effective if the paths around them are also protected. What should you do? There isn’t one magic setting that solves this. Start with the basics. Protect your CI/CD secrets Use appropriate secret management mechanisms and avoid putting long lived credentials where they don’t belong. Keep cloud permissions narrow Give GitHub Actions and other automation only the permissions required for their specific jobs. Prefer short lived credentials where practical Reducing the lifetime of credentials can limit the damage if they are compromised. Monitor configuration changes Changes to IAM permissions, S3 policies and other security sensitive cloud settings should be visible and investigated when necessary. Treat CI/CD as part of your attack surface Your security assessment should not stop at the production environment. Review the repositories, workflows, credentials, runners, artifact storage and deployment mechanisms that connect development to production. Verify your controls Don’t assume a policy is working because it exists. Test whether a compromised workflow or identity could actually reach resources it shouldn’t. The question isn’t “Are our GitHub Actions secure?” That’s too broad. Ask something more practical: “If an attacker obtained one of our CI/CD credentials today, how far could they get?”
Then follow the path. Could they access AWS? Could they modify an S3 bucket? Could they change a build artifact? Could they influence a deployment? Could they get around the controls we rely on before code reaches production? Those answers tell you much more about your actual exposure than a checklist of security settings. Your pipeline is part of your production environment Modern applications are rarely deployed manually. Code moves through repositories, workflows, cloud identities, build systems, artifact stores and deployment platforms before it reaches your customers. That entire chain needs to be protected. Because if an attacker can compromise the process that you trust to deliver your software, they may not need to attack the software directly. At Cyenetic Solutions, we help organizations assess the security of their cloud environments and CI/CD pipelines, identify excessive permissions and configuration weaknesses and understand where an attacker could move if one part of the environment were compromised. Could your CI/CD pipeline be used to bypass the security controls you already have? Talk to Cyenetic Security about a Cloud & CI/CD Security Assessment. Find the weakness. Fix the risk. Protect what matters.