User and Group Role Security: Your toolchain should manage the users and groups-of-users appropriately, to limit code writing, check-in, promotion, and deployment to the right people. If your preferred processes require permissions from QA, Security, and Business Owners, you need to be just as vigilant about who can approve those actions. Your security has to have enough traceability behind it so that you always know who performed the action or approval, even on shared systems or those fundamental utilities that do not appear to pose a security risk. Your toolchain needs to enforce signoff by all appropriate parties wherever appropriate. Your toolchain should make it simple to exclude individuals or entire groups of users from a process when they no longer need access.
Workflow and Process Level Security: Your toolchain should make sure only the right people, administrative tools or schedulers can initiate processes. Even when processes are accessible, each participant should only be able to participate at the appropriate stages of these workflows, provide data or approvals only for relevant stages and have visibility into data that is relevant to their role.
Environment and Machine Level Security: Your toolchain should lock down the ability of your DevOps workflows to interact with environment and machine resources. Controlling access to file and network resources should be considered for every automation process under DevOps. Ensure that you have a clear audit trail to indicate when they do change even for approved users or applications.
Function Level Security: Your toolchain should restrict misuse of software. Different hosts require different levels of security, and even some of the most common utilities can cause far more damage on one server than another. Your tool-chain should be able to accommodate configuration at an administrative level to prevent mis-use of the functions on any individual server and lock out the ability to invoke the function with destructive options.
Configuration Level Security: Your toolchain should manage configuration of systems and software. Only the right people or processes should have visibility or control of the configurations, and those configurations should only be allowed to change in a controlled, auditable way.
OS Level Security: Your toolchain should put the tools in place to both log and monitor for changes in OS security policies, file content changes, file ownership and permission changes, and local accounts. When tied together properly, the toolchain will make it easy to trace when and where each change took place.
DR Level Security: Your toolchain should put the tools in place to help your applications be available in a DR environment on demand. This is not just an organizational requirement from an operations point of view; so business can continue, but also a security gap that must always be closely thought of as part of the overall DevOps strategy.
Securing Knowledge Management: How easily is your DevOps knowledge captured, searched, archived or version controlled? Process and related tool chain knowledge in most organizations is made up of tacit and ad-hoc information that disappears with employee transitions and team rollovers. Ensure the security of your intellectual property by mandating that your toolchain considers this often overlooked security aspect.
Security by Future proofing: Change is inevitable. Tools change, processes change. Any toolchain management solution should consider the agility of the toolsets as well as allow for tools to be brought in or taken out of a landscape with minimal disruption to end users or the processes.
By building these considerations into the toolchain itself, you can avoid many of the pit falls that cause security concerns, and arm your security experts with the information they need to evaluate application and service changes quickly.