Bitrise Security Caution Notice: Recommended Steps for Prevention Against Poisoned Pipeline Attacks Through Public Repositories
Git providers have noted an increase of poisoned pipeline attacks that can result in serious security vulnerabilities, which can be exploited by attackers to gain unauthorized access to sensitive data, compromise the confidentiality, integrity, or availability of the system, or even gain control over it.
At Bitrise, our customers' security is of the utmost importance to us. On May 5th 2023, out of an abundance of caution for our customers’ security, we enabled manual approval of all pull request (PR) builds submitted from forks for any customers where we could not confirm if they were connecting to a private repository.
If you have the following App settings in place, you could be vulnerable to a poisoned pipeline attack where it would be possible for a third-party to trigger a PR of a public repository, triggering a build of a private app. This would only be possible if your app has the following settings in place:
- Your app uses a public repository
- Your app on Bitrise is private (not a public apps where we enforce manual approval of pull requests submitted from forks)
- The Bitrise feature to manually approve PR builds is disabled
- Your organization exposes secrets in PRs
Given these pipeline attacks, this is a risky configuration. While some customers may want to proceed, we highly recommend you keep enabled the requirement to manually approve PR builds submitted from forks.
Private repositories connected to private apps on Bitrise: If you are connecting to a private repository, this specific warning is not applicable to you.
Note: This is an interim notice for support purposes and may be updated or removed. Please contact support if you have any questions and please always follow procedures that meet your company's security requirements.
Known issue with the M1 open beta: Simulator GPU hang
There is a bug in Apple’s hypervisor framework that can cause issues in virtualized environments like ours. The issue can occur whenever a simulator is launched: for example, our Xcode Test for iOS Step uses an iOS simulator to run tests. Once the simulator starts, your build can hang indefinitely. The issue has already been reported to Apple, under the following ID: FB10015465.
In order to confirm that you are having this issue, we recommend running the following command:
You might see a similar error:
[10090.671982]: [10090.671990]: [10090.674754]: [10090.674799]: [10090.674806]: [10090.674864]:
If you encounter this issue, please vote here so we can better see its impact. Thank you!
Stack deprecations effective May 23rd, 2022 - Xcode 10.3, 11.6, 12.0, 12.1, 12.2 and 12.3 stacks
We recently deprecated a few of our Xcode stacks and will remove them in a scheduled platform update on May 23rd, 2022.
Builds that are using any of the mentioned stacks will be automatically migrated to 13.2.x Xcode version.
- Xcode 10.3 → Xcode 13.2.x
- Xcode 11.6 → Xcode 13.2.x
- Xcode 12.0 → Xcode 13.2.x
- Xcode 12.1 → Xcode 13.2.x
- Xcode 12.2 → Xcode 13.2.x
- Xcode 12.3 → Xcode 13.2.x
You will be able to change stacks even after the deprecation on your own using the Stacks selector page of your workflow.
As of the 25th of April, Apple will start requiring all apps being built with Xcode 13 to be accepted for App Store submissions. We suggest switching to one of the Xcode 13 stacks.
Deprecation is also presented on the bitrise.io website, everywhere the stack’s title/description is presented, including the stack selector.
You can read more about our stack update and deprecation policies on the topic here.
Bitrise has Suspended All Sales in Russia
Bitrise joins the international community calling for peace and the respect of established international law and has suspended all sales in Russia.
In the past few weeks, governments around the world have imposed a range of sanctions on individuals and territories in response to Russia’s invasion of Ukraine. We believe that the economic sanctions being imposed are an important mechanism in the efforts to restore peace. We are committed to complying with sanctions, and have stopped sales in Russia until further notice.
We are committed to supporting our Ukrainian customers and partners. We call for a peaceful resolution, have made direct donations to relief organizations, and have matched employee contributions.
We stand with Ukraine.
Bitrise service continuity during the situation in Eastern Europe
Just like everyone else in the world right now, we are closely watching all the news concerning the situation in Ukraine. We as individuals and as a company reject all violent actions and stand for peaceful resolutions. We strongly stand for freedom, equality, and humanity: our heart and all our thoughts now go to Ukrainians and their families. Our priority is the wellbeing of our people, and the safety of the Bitrise community, so we offer all possible help, support and consolation to our friends.
As we follow the situation unfolding in Ukraine, we are fully prepared to continue services without disruption. Even though we have a presence in neighboring Hungary, we currently have no reason to expect our team there to be directly impacted. All supporting functions (such as support and customer success) are global functions executed across several countries and continents, and will continue to operate as normal. Additionally, the Bitrise data centers and vendors providing critical infrastructure for the Bitrise platform are US based.
Bitrise’s response to Log4j vulnerability (CVE-2021-44228)
This article is intended to provide you with updates on the Log4j vulnerability (CVE-2021-44228) and its impact on Bitrise and its customers. Executive summary: Bitrise customers are not affected, but please check any 3rd party steps/code.
A critical vulnerability - also known as Log4Shell or LogJam - was found in Apache Log4j, an open-source Java library (more details: CVE-2021-44228).
What does it mean for Bitrise customers?
After learning of this vulnerability, we immediately commenced an investigation. Upon a thorough review, we have found only a single instance of the use of Log4j, which was resolved through a patch to the affected system. Further investigation of telemetry and monitoring turned up no signs of successful exploitation before the patch was deployed. Based on our investigation and this mitigation, we believe Bitrise is currently not affected by the Log4j vulnerability, and no customer through its use of our codebase was impacted.
3rd-party and custom steps
Even though the official Bitrise Steps do not use Log4j and therefore are not affected, Bitrise has no control over the 3d party steps and the custom code developers might utilize during builds (e.g. within the Bitrise script step). We recommend that customers reach out – and confirm – with applicable third-party step developers and internal developers responsible for custom code, any exposure to this vulnerability.
In the workflow editor, official Bitrise Steps are highlighted with the “B” icon:
In case you have any questions or concerns, we're here to help.
Scheduled weekend maintenance on Bitrise - 18 Dec, 2021
Starting April 15th 2021: Additional IP subnets coming to Bitrise
Starting April 15, Bitrise will be expanding our platform and adding new IP address ranges that the build environments will use to provide a better and faster service for all Bitrise users.
If you have configured source IP filters/policies in your Bitrise workflows (e.g. to provide access your self-hosted Git repository, Artifactory, etc.), you will have to add the following new IP subnets to these allowlist policies .
Build VM internal subnet
Xcode and VS4Mac stacks
Please note that this update may affect your builds if no action is taken, so please be sure to update the IP ranges by April 15.
If you are not using the source IP of the build environments for any filtering then no action is required on your part.