7. 4. 2021
As developers, we are always keen to make sure everything is safe; however, we don’t live in a perfect world and therefore data breaches are inevitable. Because of such events, we had to make the correct decisions regarding our security from the beginning of Codeac’s development and ensure that our clients feel safe when they entrust their code to Codeac for analysis.
Simply put, working with the code of our clients is a sensitive matter. Therefore, we never thought of using security as one of our selling points because being one of the leaders in the automated code review industry, secure service is a NECESSITY.
We are able to achieve a secure solution by implementing technologies with the highest security standards such as AWS Lambdas and Stripe gateway. Along with these providers we designed Codeac to be as much “plug&play” as possible. This allows us to take advantage of GIT providers and leverage existing permission schemas in Codeac.
We have collected the most frequent questions regarding security in our architecture and Codeac’s processes for you, so let’s dive in to show you there is nothing to worry about:
Codeac starts analyzing your code after every commit you make. Each commit is analyzed in a separate container, which is discarded immediately after each analysis. The only information that we save is the detected issues with the small snippets of code (~15 closest lines of code) to give you a better context.
Since we work with clients’ code we need to be confident that the code is safe during the whole process of analysis. Therefore, Codeac runs completely serverless on AWS Lambdas, leveraging the security of one of the most prominent players among cloud providers.
These architectural decisions allow us to analyze every commit separately, keep the code for the minimum time and build multiple strong security layers with AWS Security.
If you want to learn more, check out this video about AWS Lambda functions security.
We don’t store your code as it only flows through our systems during the analyses. The only exceptions are small snippets of code around the detected issues.
These lines of code are the ~15 closest lines of code around the detected issue to provide you better understanding and context. If somebody else would get into our system, these small chunks of code should be useless because they never carry enough business logic.
Codeac doesn't write anything in your code and for analyzing your code the read permission would be enough.
However, for the continuous monitoring of every new change in your code and automated process of code review, Codeac needs to register a webhook to your repository and that requires the write permission. In addition, we also need the write permission to update the commit status ( success & fail ).
We would only ask for what we need but the permission models from the GIT providers don’t allow us to do that. For example, here is the GitLab’s Issue where this is discussed and we are in touch with GitHub and Bitbucket regarding the same issue as well.
We take your permission settings from GIT and use them at Codeac. In other words, if somebody in your organization has only read permission for the repository, s/he has the same rights in Codeac as well.
As developers, we know how much effort a new tool implementation needs and that’s why we don’t want to overwhelm you with setting up access rights that are already managed in your GIT. That way, you only need to invite your colleagues in Codeac and don’t have to worry about the part that is already done once.
We don’t save any of your code on our side and we take the permission schema from your GIT. Consequently, nobody (not the internal Codeac team nor anyone from your side) can access the whole code from Codeac and only people from your GIT organization can access the Codeac’s results and snippets of the code around the error.
However, the Codeac team can access the telemetry and logs of the results of the analyses. The reason for that is to help you with the explanation of specific issues and writing the tailored configuration file to avoid false-positive alerts. This approach is very welcomed by our clients as we can provide help even without any access to the source code.
Following our philosophy of “Don’t reinvent the wheel”, we decided to implement Stripe as our payment gateway as Stripe is certified as a PCI Level 1 Service Provider .
With this implementation, we don’t store any of your payment information on our side. You can learn more about Stripe security .
Every day, while developing Codeac, we make sure that our security complies with the latest standards on the market. Thanks to our architecture, strong security providers, and keeping the code for the minimum amount of time possible, our clients can rest assured when entrusting their code to us for analyses. Plus, this allows us to be transparent, so if you have any questions, please feel free to reach us at email@example.com.
Use your favorite version control system to sign-up.Sign up for free