Understanding DevSecOps: 5 Key Elements

If your company is forward-thinking and obsessed with digital transformation like many enterprises today, then it’s probably heavily invested in Salesforce. This is a platform that allows you to get the best out of your investment with customizations that go beyond the ordinary limits. However, all this freedom means you must be prepared to install ongoing adjustments to your business process’ tools to take care of your security. DevSecOps comes in at the intersection of DevOps and Security, and if properly configured and implemented, has the ultimate power to safeguard all your Salesforce configurations and customizations.

Whenever there’s a severe security breach, it shows us how useless technology can be if not correctly configured. It’s up to you to ensure that all your technology investments are set up correctly, especially for customer-facing systems like Salesforce.

So, let’s get to the finer details and start with the big question of the day…

What is DevSecOps?

Security has many parameters unique to each system, and for Salesforce, this is mostly managed through permission sets, profiles, and sharing rules. All these put together provide control over access to the service (which includes admin permissions and login) and access to data at the field, record, and object level.

The organization of the security parameters in Salesforce is important, but does not provide the full extent of what it takes to protect your investment. Speaking of which, you also need to think about protecting your settings, source code, and data from being accidentally deleted or overwritten.

Others argue about the possibility of recovery from incidences likely to arise from deletion or overwriting of data, source code, or settings. Still, the actual loss is the time it takes to restore the lost items.

Let’s review five key elements paramount to your DevSecOps practice on Salesforce and how best to go about dealing with each.

#Single Source of Truth (SSoT)

Unlike in other platforms where setting up a Single Source of Truth (SSoT) is straightforward, in Salesforce it requires serious thought. However, you can make changes both in Production and Sandbox environments in no time in Salesforce.

In DevSecOps, this is critical because of the possibility of losing work. It’s easy to lose all the changes you’ve made in production or test with just one deployment.

To secure your investment from this mess, it’s advisable to make changes in development environments and save them in a version control system like Git to lower your chances of overwriting the changes. This way, admin and developers have one source of truth for changes they may want to make.

#Audit Trail

An audit trail proves that you made the right changes and that the wrong ones were never done. It’s all about compliance and security. With one single source of truth set up in a version control system, audit trail answers the critical questions around who made the change, when it was done, what changed, and why the change was made.

With a Git repo as the single source of truth, you can capture all the changes to your code and settings, changes in configuration data, and more, which are useful in Salesforce applications like CPQ. Furthermore, the system for capturing changes in Salesforce is relatively advanced, with audit records readily available in Salesforce standard reports.

Industry leaders, Copado, recommend using User Stories to manage change management releases so that you also get to know the “why” behind changes instead of only getting the ‘who,’ ‘what’ and ‘when’ with git Repos.

#Quality Gates

If you want to guarantee your Salesforce investment will last and yield the right ROI, then you must protect all the functional enhancements you have from day one. Most organizations have had to devote thousands of person-hours to ensure the existing implementations are working correctly, only for such to be ruined with just a single unmonitored, incorrect change.

With quality gates in place, you are safeguarding the perfect operation of your current new features and protecting those made earlier. In most circles, functional testing, the quality aspect that guarantees the perfect working on new features, has had to be used with tools such as Fusion, Selenium, and Provar having to be used.

One way to ensure you are covered all the way through is to employ source code quality standards so that if the engineer who began the journey with you leaves, the next engineer will simply scan the code and identify with it quickly because it was written following a set standard.

Another technique or approach that needs to be put in place is Static code analysis, which will help you unearth bad practice within the code that would otherwise hamper its performance.

As an organization, you can invest in Unite tests to ensure code is working as expected. Apex Test Coverage is another way of ensuring everything works as expected.

#Compliance

Although new to the Salesforce world, automated monitoring and compliance scans ensure that system, data, and record access controls do not open up security holes in your org service.

Least Privileged Access means that users only have access to information they need to do their job and nothing more. This is what Salesforce implementations always need to think of. It’s often considered inconvenient, but the consequences of not are too heavy to risk.

Investing in a strong compliance system that also alerts, in addition preventing deployments that violate the laid down rules, will safeguard your Salesforce investment. Such a system would enable fine-tuning to allow only suitable levels of control in each stage of the deployment channel. If you want success with your investment, you’d rather spend hours creating a complete set of rules for your organization.

#Backups are still golden in DevSecOps

Just like in other areas of IT, backups are one way of protecting your data. In Salesforce, having copies of your metadata safely backed up means you can restore them anytime should an unfortunate event lead to data loss. This has primarily been proven with the recent history of lost profiles.

Creating backups should be targeted not only for the data, but also for your code and configurations.

To safeguard your metadata, it’s advisable to put a release process in place that captures every change happening in every environment. This can be achieved using Git as a Single Source of Truth (SSoT) and tying changes to User Stories. This way, you have all the necessary backups for Restore and Rollback.

Sometimes it’s hard to implement data backups due to the size of datasets involved. To save yourself from this headache, choose a data backup tool that does continuous incremental backups and, at the same time, allows you to restore your Salesforce to a selected point in time with the backup records matching the selected period or date.

#Promotion vs. Monitoring

Finally, after all the above has been configured and in place, it’s time to decide when to test. This is actually the balance between carrying out tests during the promotion of a change from one environment to another versus scanning the entire environment with every change.

In an enterprise environment, running apex tests and the functional test could take hours. Considering a continuous delivery scenario and changes hitting an environment several times an hour, it would only stall full tests as most full tests would not run to completion because of changes hitting every now and again resetting it to start anew.

The best way out in such scenarios is for companies to run tests scoped only to the individual changes and conduct environment-wide tests on schedule. In ideal situations, your DevOps tools should be able to identify the scope of impact and only conduct tests when required. This is a long-term goal, but the industry is heading here.

DevSecOps is the sure way to protect your Salesforce Investment

Protecting your Salesforce Investment is paramount, and it’s good to understand that it’s a work in progress. You must never think you are completely safe or done. If you haven’t started the journey, get started. If you think it’s too hard, recognize that it’s worth it even if it takes time.

Regardless of your situation, prepare a plan and automate everything possible and use approval processes where automation fails. Don’t worry if you are slow in the process, just make sure you are steady. You will minimize your losses and if you think this is jsut talk, give Capital One a call.

Plumlogix promises a seamless experience if you need help safeguarding your Salesforce and realigning your practices. Talk to us for the best DevSecOps solutions. Call us (888) 318-8883.