Streamline your SDLC during SOC2 audits to make them effortless

Security should no more be an afterthought for a company. With the rise of data breaches, companies need to take the necessary steps to handle sensitive customer data and themselves from security risks and threats.  

SOC2 (Service organization control) is a framework developed by AICPA and is used to audit, assess, and attest a company's compliance and security practices against the five security principles: Security, Availability, confidentiality, integrity, and privacy.  

A SOC2 builds a robust security & compliance culture with the organization. It provides the ability to create new and improve existing customer confidence and speeds up the sales cycles by eliminating security & compliance as a sales objection. A SOC2 report includes organizational information such as descriptions, roles, performance reviews, etc., and technical data such as data encryption, employee devices, and version control.

How does SOC2 impact a software development lifecycle? 

A software development lifecycle is an integral part of SOC2 examinations. Auditors are concerned about details related to each software modification, such as formal documentation like comments of Pull Requests, Jira tickets, reviews of the change or Pull requests, was the change approved and by who? and was the change/difference tested. 

These concerns may seem significant obstructions to collaboration and speed for the software dev team. Still, it is essential to adhere to compliance requirements to maintain a secure and healthy codebase. If your company uses a source code management tool such as Github, facilitating protected branches and enforcing native security policies on these branches will make audit experiences sustainable. 

"You can protect important branches by setting branch protection rules, which define whether collaborators can delete or force push to the branch and set requirements for any pushes to the branch, such as passing status checks or a linear commit history. You can enforce certain workflows or requirements before a collaborator can push changes to a branch in your repository, including merging a pull request into the branch, by creating a branch protection rule. By default, each branch protection rule disables force pushes to the matching branches and prevents the matching branches from being deleted. You can optionally disable these restrictions and enable additional branch protection settings." - Github protected branches 

Protected branches rules & configurations. 

Require status checks to pass before merging

  • Required status checks ensure that all continuous integration (CI) tests pass before branches can be merged into the protected branch by collaborators.

  • CI tools can provide a status check update on each perspective change.

  • Any person or integration with write permissions to a repository can set the state of any status check in the repository. Still, you may only want to accept a status check from a specific GitHub App in some cases.

  • Utilize these rules and configurations to display testing requirements for every change made to reduce evidence gathering while SOC2 audits

Require pull request reviews before merging

  • Code reviews are essential for any software development lifecycle. This check requires at least one approved review before merging a pull request.

  • Such checks also demonstrate the separation of duties principle by preventing engineers from merging their pull requests without a secondary review.

  • If a collaborator attempts to merge a pull request with pending or rejected reviews into the protected branch, the collaborator will receive an error message.

Have Code Owners review requested PR's 

  • Code owners, a predetermined set of users, are automatically requested for a review and must approve the change before merging a pull request.

  • Repository owners can add branch protection rules to ensure that the owners of the changed files review the modified code.

Enabling these security rules and configurations makes acquiring and maintaining this evidence for SOC2 and other compliance assessments easier and less complicated during audits. 

Reference Links :

Protected Branches, About Code Owners

Previous
Previous

Should you Shift-Left or Shift-Right?

Next
Next

Delegated authorization v/s Federated identity