Last week, we looked at the people and technology you need to build a strong DevSecOps foundation for your organization, and the importance of having a Center of Excellence (COE) with a clear, actionable charter.
Your DevSecOps charter should define in detail how you expect your COE team to engage security throughout the development lifecycle. Putting these rules of engagement down on paper is a great way to get the cross-functional communication started — from requirements gathering and design, to development and testing, and all the way to training your users on how to take full advantage of new system features.
You may find it useful to organize your rules of engagement into the distinct phases below, with which many DevOps pros will no doubt be familiar. As you put your plan to paper, here are some questions to ask and considerations for your team to discuss:
- Deploy, Operate, and Monitor
As you approach new roadmap initiatives, individual projects, or feature enhancements, how will you define and design for the threat models presented by the project? Is there a risk for data breach or data leakage, and how will you proactively prevent that from happening? What national or local security policies do you need to plan for as you develop your requirements? In our experience, these threat models may look similar for companies within an industry like Healthcare or Financial Services, so do your research and plan for these questions together!
Once you define your requirements and have a build plan in place, it’s important to look at your backlog and ensure you have made accommodations for all your security requirements. Do your backlog stories have acceptance criteria for the security needs presented by each feature? Have you embedded stories for permissions and system settings that might be impacted? In our experience, there are also different considerations for declarative features versus ones you might custom-build:
- Custom Development: For custom-built features that might require classes, code, triggers, custom metadata, and more, how will you be reviewing that code for quality? Be sure to embed a manual code review in your development processes to make sure your developers are writing code that meets the security requirements you’ve outlined. Don’t forget to inspect any open-source libraries you might be using, and any other code assets impacted by your custom development work to ensure they all meet muster. Finally, how might automated code scanning tools help your development process? In our experience, these types of tools can really help in your spot-checking and quality control efforts!
- Declarative Development: Since so much can be accomplished with clicks and not code on the Salesforce platform, it’s imperative that your team defines standards and best practices you expect in declarative features. As your Salesforce environment grows, it’s important to include clear descriptions on fields and objects for how they’re used. Be diligent about labeling your process builders and flows, and applying appropriate security settings to each and every new declarative feature you build. In addition to this manual effort, there are some great automated tools that can help you make sure the declarative configuration in your org is following security best practices like data classification on every field, profile and permission sets auditing, and data visibility controls that help surface the changing shape of data and configure smart alerts to warn them of unusual changes.
Regardless of your custom or declarative development efforts, how will you plan to track the user behavior of your new app, release, or feature? In our experience with heavily regulated Financial Services and Healthcare companies, it’s important to include items in your build backlog that help with employee behavior tracking and alerts on suspicious activity, especially if it might contain large data extracts, personally identifiable information, or other regulated activities like chat or support channels!
Most DevOps teams are comfortable with embedding security reviews inside their existing QA (quality assurance) and integration testing processes already, but how can you take it to the next level? To evolve your DevSecOps posture as you approach testing for your new features and releases, consider these important emerging requirements:
- Penetration Testing: This will become more prevalent as Salesforce apps become more client- and partner-facing. What will be your penetration testing plan as you expose apps to others outside your collective VPNs and firewalls via communities and Experience Cloud, Lightning Web Components, custom mobile apps, chatbots, and more?
- Interactive Application Security Testing: There are increasingly advanced tools that can run in your browser to identify security issues within your Salesforce application at runtime. These will capture runtime vulnerabilities and analyze 3rd-party modules, such as managed package components that SAST does not include. Do you have a plan to incorporate them into your functional testing process and remediate the issues identified?
As your teams move past the development and testing phases into your release plan, security should have a seat at the table! Auditing is a great topic to consider: How will you audit the trail of changes? How will you track who asked for the change and why the change was made? What does the change connect to and when was it done? The Salesforce audit trail has limited information about auditing and isn’t alway easily reportable, so it’s important you track changes carefully. Your audit and release log is a key component of your DevSecOps workflow, and tools like Confluence, Jira, and Git repositories can be instrumental to your release management operations.
5. Deploy, Operate, and Monitor
Finally, as your team releases features and functionality to your end users, there are many DevSecOps considerations to think about:
- Training and Change Management: How will you educate and train your users about the security requirements and features in your new release? How will you monitor their usage and the uptake? What’s in it for them and how will complying with these security requirements make their lives easier or better? It’s important to communicate these benefits and expectations in your training efforts and release notes.
- Backup and Restore Capabilities: In our experience, it’s critical that you have your data and metadata backed up in an easily restorable way as you plan for your deployments … just in case. What are your plans to make sure these backups get created as part of your deployment plans? What tool(s) will you use? Please note that some environments may require specialized tools — we can certainly help advise on what might be the best option for you!
- System and User Monitoring: As you prepare for deployment and monitor the uptake of your new features and releases, Event Monitoring can be a very useful way to receive alerts and keep tabs on the situation. Salesforce’s suite of Shield tools provides some nice dashboards, and many integrate to tools like FairWarning, Splunk, or New Relic for application development monitoring and security monitoring needs so that they can keep track of user behavior across systems.
Let Silverline guide your DevSecOps journey
With the right DevSecOps processes in place, you can shorten the development lifecycle and ensure that your business is capturing the full value of your Salesforce implementation. Silverline’s Salesforce DevOps services empower optimized, scalable, and reliable development operations, continuously improving your DevOps processes as Salesforce improves their developer and deployment automation tools. Learn more about how we can help your organization.