The reshift software platform is designed to help software development team and small to medium-size businesses (SMB) acquire a basic level of security coverage within their software development workflow. Software Secured has been helping SMB for over 7 years to integrate application security within their organization, and by shifting application security left (earlier) within the software development pipeline. The reshift philosophy is to integrate into the developer’s workflow of writing code, code review, fixing bugs and deploying. Reshift’s first step, within the larger picture, is to integrate into a software projects continuous integration/delivery (CI/CD) pipeline. Reshift offers a SaaS-based user interface and downloadable plugins. The plugin integrates code analysis into a project’s build cycle. Every time a software project builds, the reshift plugin will analyze and upload reports to the reshift servers for processing; Informing software development teams of security violations introduced on a continuous basis.
With a deep understanding of application security, our security model for reshift allows us to adhere to best practices for creating features, securing customer data and being transparent throughout the entire process. This document outlines the processes and security controls that we introduced to ensure that customer data is private and our security practices protect their data.
Our best practices include:
• Regular Penetration Testing
• Code review on every code change
• Security documentation
• Encryption of data in flight and at rest
• OAuth2 authentication with 2FA capabilities
As a SaaS-provider, defense and best practices is a layered approach to protecting the privacy of customer data. A well-architected solution will have gates and checkpoints at every level throughout the SaaS solution including but not limited to physical security, transmission, infrastructure access, application, and data security. Topics covered within the document include defense of user information during authentication, data access during operation and outline data in-flight and at rest.
Reshift integrates with all the major source code repository providers; GitHub, Bitbucket and GitLabs. Due to the integration with these vendors, reshift offloads responsibility of user credentials to these providers. Reshift does not store or transmits any user credentials, all user login and access happens on the client side (in-browser) and only between the client and the source code service provider. Outlined below is the authentication flow for the reshift login process with a code repository service provider, following the OAuth2 authorization grant flow.
Note: The access token is a short-lived access for permissions on behalf of the user. Users have full control to revoke access to that access token through the source code provider’s website. Additionally, once the access token expires, reshift will not be able to use that access token to access the service provider for data on behalf of the user.
Reshift integrates with all major source code repository providers; GitHub, Bitbucket and GitLabs. This integration offloads the responsibility of user credentials to the source repository providers. Reshift, supports Two-Factor Authentication (2FA), through the providers, during OAuth2 credential negotiation. As in the above section:
The two important points to note is that 2FA is supported by GitHub, Bitbucket and GitLabs. Reshift delegates authentication and the supported workflow of 2FA, alleviating the need to store sensitive information about user credentials within its own internal infrastructure.
Software Secured fully appreciates the paradigm of granting less, and reflects it within the OAuth2 grant scope when asking for access permissions with a service provider. Take for example GitHub, reshift provides two layers of access permissions. Initially, during the sign-in of a user through GitHub, users are prompted for the specific permissions allowed by reshift within GitHub. Reshift will only ask for access for personal projects of the user. Reshift does not ask for permission to access any organizational projects and resources including organization open source projects. Within the second stage, users can opt-in to give reshift additional access to organization information. Users will be able to apply scans and reporting to private and organizational private software projects. At Software Secured, we believe less is more when it comes to security. Giving users the freedom to have a more granular control for organizational access is a value-add to the user.
Permissions in reshift are provided by the underlying repository provider (GitHub, Bitbucket, GitLab). If a user has read access to a particular repository on Github, then they can also see the project on reshift. A project may be missing from the list of accessible projects if the required OAuth scope has not yet been granted. For example, a user may not see their organization projects if the organization has not granted permissions on GitHub.
When a project is added to reshift, any user that has read access to that project will see it in their list. The project does not need to be added for each user; in reshift a project can only be added once, and applies globally.
Permissions are cached for performance reasons, but are refreshed every 10 minutes, and before a project is added.
Access to the project security reports follows the same permission model as the project. Reporter tokens are used to grant upload access, but do not affect which users can view the submitted reports.
In order to upload a security report to a reshift server, a report provider token must be supplied. This controls who may upload to the server, and provides a means of grouping similar reports together. As an example, a build server might upload using the “Daily Build” reporter token, while another build might be configured for a “Production Release” reporter token. These reports will be aggregated under the project in the scans view, but can also be viewed as individual streams of reports. If a token has been compromised, or simply isn’t needed anymore, the report provider token can be revoked, ensuring that no reports using that token will be accepted.
Source code is not stored on reshift servers; however, file names, git blame and git version information is stored for lines affected by a particular security issue. When an issue is viewed in triage, the source code is queried from the repository provider for each request.
Reshift does not access the source code in any background processing.
The artifacts are serialized to files within a special folder during build time and removed when the upload to the reshift server is complete. If there are any failures within the build or upload phase, the intermediate files will also be cleaned up. Once the artifacts are collected, the report bundle is sent to the reshift servers to be collected and analyzed. Further information can be found within the below sections on specific of security during transit and at rest.
The code graphs, better known as static call graphs within the software development community are the graphical representation of the source code. They outline the interconnections between subroutines within a computer program. They consist of a node and a vertex representing a relationship between a caller and a callee within a software program. The important point to note is that call graphs are a byproduct of the source code itself, and the conversion between source code and code graphs have varying degrees of precision, hence are a lossy conversion. There are many tools to generate code graphs from source code, however, there is currently no tool available today to convert code graphs back into their source code counterpart. Reshift generates code graphs of the source code being analyzed and transmits them to the reshift server to be analyzed for security violations against its global knowledge base.
The Report Bundle, better described within the overview section, is generated on a per build basis and its artifacts are created to be consumed by the reshift servers. The artifacts are serialized into a proprietary format. To send the report bundle to the server, the reshift-plugin requires a unique reporter token, generated during the Add Project steps. If a report token is supplied to the reshift-plugin, the reshift-plugin will establish an encrypted TLS 1.2 connection between the build machine and one of the reshift servers. Once a successful connection has been established, the reshift-plugin will use the encrypted channel to send the report bundle.
The reshift servers will deserialize the information within the report bundle and discard the original report bundle leaving no trace of information within the server. The data within the report bundle is stored within an encrypted database housed within a secure data center.
Database security and protection is important to reshift and its customers. Reshift currently deploys its database behind a world-leading cloud infrastructure provider. The database is fully encrypted in case physical access is gained behind the cloud infrastructure. Software Secured also follows best practices for database management including routine backup, staging and production databases systems and user permissions and access control via the cloud provider's identity management.