In a recent episode of our Perspectives in Leadership podcast, Shea Stewart from GigaOm discussed DevSecOps technologies, cloud-native environments, and Zero Trust without disrupting workflows. Shea’s background in networking, infrastructure, solution architecture, and open source cloud native technologies gives him a unique understanding of integrating people, processes, and technology. Shea says “Rah, rah, we’re all for this” is effective. We want safer apps. People, procedure, and tools are always key. None exist. People, processes, and technology are still engaged, despite available technologies. Shea explains how to choose the finest DevOps security technologies. The audio episode contains the IT nerd’s whole thought process.
What is the value of cloud-native technology?
Shea enjoys seeing teams become more successful and creative. This aligns with cloud-native technologies, he says “I like self-sufficient teams. Cloud native technology evolved from self-service delivery. “What are some ways to break this?
What CSOs Should Know About Development and Deployment Pipelines
CSOs often face challenges with development and deployment pipelines. Shea sees many businesses and industries facing these challenges:
- Inconsistent policies and tools: Different release engines, security gates, checks, languages, and stacks are frequently used by teams. Sharing updated processes or capabilities between teams becomes challenging as a result. CSOs and engineering managers are unable to standardize processes or monitor the effectiveness of their teams using development and deployment pipelines. Every team’s situation is unique, therefore it becomes more of a quarterly effort to gather data and read reports.
- Verifying the authenticity of artifacts before release: Shea points out that this problem is very serious for CSOs. If the libraries you use are depending on open source, things upstream may have vulnerabilities or may have been compromised. This could manifest as not being able to confirm whether an internal employee who is about to leave has an unfavorable impression. “Once the library is within your package, you cannot confirm its legitimacy. After passing through your general checks and balances, it suddenly begins to run in production, says Shea.
- Not noticing security issues until they’re in production: There are significant difficulties in identifying security concerns after a system has gone into production. Shea cited a Canadian government system that had to be shut down because of a flaw and was unavailable for a week. “It’s much better if we can identify that sooner. We don’t actually know there’s going to be a problem until runtime until we actually add more tooling and processes to pre-deployment. It has typically been there for a while, says Shea. “In the next five years of my professional life, I hope that we won’t be discussing unpatched systems because we now have the ability thanks to automation and DevOps security solutions. That is not a valid defense. We should always be patching.
The Importance of Planning and Inclusivity When It Comes to Security
Saying everyone should be responsible for security isn’t enough. Effective implementation requires organizations to return to their people, processes, and technology. By including security early, rather than midway or at the end, planning and inclusivity are achieved.
Key platform and application teams can immediately incorporate security teams. Shea says this promotes communication between the application or platform team and the security team. Standardized communication removes several barriers. It promotes shared understanding. Similar technologies can increase workflow and teamwork.
Does Zero Trust Hamper Productivity?
According to others, zero trust’s major challenge is blocking access without stopping workflows. Adapting to change is difficult, and people often lose access to servers, platforms, and technologies they never needed.
Shea defines Zero Trust as making no assumptions about the target environment. We could extend Zero Trust beyond the network, so I didn’t have to worry about it. Hopefully, my network personnel has handled that. I can do nothing. This changes attitude. When you look at how teams communicate, you’ll notice that things are misinterpreted, not misconfigured.
Tools and Technologies for DevSecOps Implementation
In GigaOm’s radar report for subscribers, DevSecOps tools are rated for key criteria categories. Shea emphasizes the availability of a range of DevSecOps tools and services in this area, which range from simple fixes to human-based coaching to provide security education. He urges businesses to keep a few important aspects in mind when selecting tools and technology for DevSecOps.
Start by considering the tools you are currently using. If you use GitHub rather than GitLab, you may have two different strategies for adding additional DevSecOps technologies to that source code management system. Examine the vendors you currently do business with. Check out what RedHat offers in terms of DevOps security technologies, for example, as you may be able to quickly add them to your current support agreements if you already use RedHat. They might provide a piece of the puzzle.
Finally, be aware that these products have a variety of uses and that no one supplier or tool can satisfy all of your requirements. According to Shea, a solid pipeline should include at least three or four DevSecOps tools, if not a few more. You can use a ton of free resources that are currently available. Additionally, anything is always better than nothing.
