Security attacks are getting more sophisticated and targeting a wider array of system components. This makes preventing and recovering from them more difficult when security knowledge and responsibilities are siloed within an organization. It is increasingly more important to ensure that everyone in an organization has a stake in security and that the company’s experts integrate more deeply with other teams. Many companies claim to make security a pillar of culture, but rarely do they invest in more than the occasional training. To truly make security a fundamental pillar, it must be embedded deeper within the organization’s engineering teams and SDLCs. The latest trend in operationalizing security within tech organizations is the melding of DevOps and security professionals into a joint DevSecOps team and bringing automation, long the domain of quality assurance, into the security toolset to further reduce risk.
Experienced DevOps professionals have long understood their responsibility for keeping tabs on the security risks in their purview, but in many organizations they don’t necessarily have the tools or backing to delve more broadly into security. Often team members have I-shaped skillsets and responsibility areas, their window of involvement in security kept very narrow to strictly the operational activities of their team. This makes operationalizing security across the organization much more difficult. Especially in larger organizations where the collaboration barriers between teams and departments are more rigid, having security personnel siloed is itself a vulnerability. When security is only a small sliver of individual or team responsibilities, issues are found much later in the process and the risk level and cost of remediation rise.
Experienced DevOps professionals have long understood their responsibility for keeping tabs on the security risks in their purview, but in many organizations they don’t necessarily have the tools or backing to delve more broadly into security. Often team members have I-shaped skillsets and responsibility areas, their window of involvement in security kept very narrow to strictly the operational activities of their team. This makes operationalizing security across the organization much more difficult. Especially in larger organizations where the collaboration barriers between teams and departments are more rigid, having security personnel siloed is itself a vulnerability. When security is only a small sliver of individual or team responsibilities, issues are found much later in the process and the risk level and cost of remediation rise.
This is mitigated by embedding security within other teams in the organization. Lately, the trend towards blended DevSecOps teams with broader security oversight helps address the challenges organizations face by removing collaborative silo barriers within this area of the organization. This allows security to be shifted left in company workflows to discover and mitigate risks and vulnerabilities earlier. Ensuring security guardrails are in place earlier in the development cycle reduces the cost of security and compliance programs and reduces the likelihood of high risk issues making it to production without remediation or at least a mitigation strategy. The later a vulnerability is discovered, the more costly it is to remediate in time, effort spent, and exposure risk.
A lot of companies claim that security is everyone’s job, but often the culture of security ends at annual anti-phishing trainings and the occasional confidentiality discussion. Embedding security experts into teams like DevOps and ensuring that even experts are hired with enough security knowledge in their toolbox brings it deeper into the company’s culture and once planted, those roots will grow. In many cases converting to the DevSecOps model will be mostly painless. The actual team process will largely stay the same regardless of the development model the team is using although this shift is especially effective in agile organizations. Workloads should also remain similar, if not decrease, as the time no longer spent on fixing vulnerabilities in Production will more than make up for the added effort to find and fix security issues earlier on.
While putting security experts in roles on a DevOps team is a start, it is ever more important to hire DevOps engineers with T-shaped skillsets who may not be deep experts, but have security and compliance skills in their repertoires. Their primary duties day to day may not be security focused, however in their work with other teams, their security consciousness will rub off. They will find issues earlier in the pipeline and the teams they work will will learn from them and gain the knowledge to spot and even prevent such issues in the first place. They bring a concern for security standards into their interactions with other engineering teams and over time they help transform the overall culture of engineering into one that is more security conscious.
Automation also plays a key role in risk reduction. Much like automating tests to find bugs earlier, shifting security monitoring left and automating vulnerability checks and adherence to security policies will save additional effort and money later down the line. While shifting to this DevSecOps model does reduce risk, relying on manual processes only goes so far. Automation reduces the human element and the chance that something will be overlooked. Properly designed automation tools shift the possibility of human error even further left to where it is very easy to remediate. Having skilled DevOps engineers with security experience who can automate these activities pays off.
Team empowerment is incredibly important. By shifting activities left and automating, risk can be reduced incredibly, however it’s impossible to completely negate it. It’s critical for teams to be empowered to speak up and have proper ways to report any issues found. Making the changes to bring security into DevOps and automate the process mentioned will go a long way towards building the culture of security consciousness that is needed for this. Embedding security deeper in teams and making it part of their daily workflows and conversations shows employees that the company prioritizes security in their operations and cares about vigilance and conscientious reporting.
Adding security consciousness to the DevOps services available to the rest of the company will ensure that risks are considered earlier in the pipeline. This saves companies time and money in remediating those risks and will come at little to no cost to team workflows and velocities. Automation further reduces risk by shifting security even further left in the process and reducing the risk of human error. These changes also go a step further in making security a deeper part of company culture and disseminating knowledge of and care for security to the teams and employees that DevOps works closely with and empowering more of the organization to make security a priority. Vulnerabilities and compliance issues will be found much earlier in the process reducing the cost of fixing them and the risk of production incidents.