Why Security Shouldn’t be Sacrificed for Speed – InApps Technology is an article under the topic Devops Many of you are most interested in today !! Today, let’s InApps.net learn Why Security Shouldn’t be Sacrificed for Speed – InApps Technology in today’s post !
Read more about Why Security Shouldn’t be Sacrificed for Speed – InApps Technology at Wikipedia
You can find content about Why Security Shouldn’t be Sacrificed for Speed – InApps Technology from the Wikipedia website
Organizations have worked hard over the past decade to bring development and operations teams together. Now they must face up to the challenge of integrating another siloed function: security. Yet, there are still hurdles to overcome, as more than half (52%) of global organizations have prioritized time to market at the expense of security. Unfortunately, doing so will only escalate business and reputational risk and add costs further down the line.
The road to DevSecOps is neither quick nor easy. By tackling the necessary cultural and technical challenges now, organizations will end up in a far better place as they look to build digital success on safer and less risky foundations.
Why Security Matters
Michael is the vice president of product at PagerDuty. He has over 20 years of engineering, product management and marketing experience in the high-tech and software industries. Michael creates and drives PagerDuty’s overall product and ecosystem positioning, product strategy, community advocacy and competitive intelligence.
Although digital transformation efforts were well under way across the globe before the pandemic, the past year has seen an increased flurry of activity. With stores shuttered and consumers flooding online, it’s never been more important to have a compelling digital presence. That matters whether you’re a healthcare provider offering telemedicine or a financial services institution delivering online banking to housebound customers. The vast majority (89%) of organizations now say that digital transformation is a priority.
However, security challenges are growing, especially those stemming from the third-party open source components commonly used to accelerate development times. A 2020 study revealed that a quarter (24%) of organizations reported a breach over the previous 12 months, with 21% of these saying it stemmed from their use of such components. Threat actors are actively targeting Node.js (npm), Python (PyPI) and other repositories to embed malicious code in them. Estimates claim there’s been a 430% increase in such attacks.
The Road to DevSecOps
All of this makes it increasingly important that security be embedded in organizations’ DevOps processes. In too many enterprises, security is treated as an add-on, with products and features only handed over for scrutiny once written, tested and ready for release. Any resulting changes recommended by security teams are therefore more expensive to make, while the function itself is seen as a block on innovation. We found that 68% of CEOs demand that DevOps and security teams don’t do anything to slow the business down, and that’s just plain risky.
When implemented effectively, DevSecOps will generate immediate improvements, including fewer vulnerabilities making it to production, fewer security incidents and less time spent resolving these incidents. Human error is also reduced as automated checks and tests will be embedded into build pipelines just like QA and quality testing of code has been.
However, getting there will be a challenge, just as integrating development and operations teams and their workflows was. Security is relevant at every stage of the software development lifecycle (SDLC), so Dev and Ops need to be more security-aware, while security teams have to better understand the stages and impact of releasing software in production.
People are crucial to the success of any major change project and building DevSecOps is no different. The first place to start is building empathy and trust among these three groups. How do you do this? Consider shadowing for the duration of a sprint, so that each team better understands the other’s workflow and how they react to incidents. As we saw in our findings, a fourth party is critical to success outside of the technical teams, and that is executive leadership. Ensure security is prioritized and the transition to this new approach is understood and a common goal, otherwise your efforts and potential progress may be in vain.
Full-service ownership (FSO) is another important approach and one we use a lot at PagerDuty. In this mode, you would let security teams actually own a Tier 1 or 2 service, if it’s feasible and makes business sense, including the revisions, upgrades, release cycle and on-call rotation. Similarly, Dev and Ops teams would take ownership of a security service or process to gain visibility into how security works.
Another idea is running a security champions program, facilitated by security but with participants from development, operations and any other relevant teams. The idea is to enhance cross-team communication, by scheduling a regular time to discuss important issues, updates, changes and messaging. On the same topic, organizations should ensure development, operations and security all use the same email, chat and ticketing systems so they can better understand what the other is doing at all times. Transparency is key. Teams should be using as many tools in common as possible, documenting requests with granular detail and regularly reviewing and iterating while building new processes.
It’s Time to Shift Left
Successful DevSecOps isn’t just about cultural alignment. Security must also be integrated as early on as possible into the SDLC — known as “shifting left.” The best way of doing so is through a series of small changes, reviews and iterations. First, organizations must understand their current security posture in order to work out how best to proceed with shifting left. They’ll need to know whether there have been any recent security incidents, what their current risks are and how critical they are. Next, they must work out which critical risks can be mitigated by changing security procedures and technology stacks as well as calculating which incidents that are at risk of happening again could be resolved with changes to process.
Some common frameworks for carrying out these assessments include OWASP’s DevSecOps Maturity Model (DSOMM), NIST’s Infrastructure Security Framework, OWASP’s Software Assurance Maturity Model (SAMM), and the Building Security In Maturity Model (BSIMM).
Finally, don’t forget the training and education piece. Activities could include threat modeling to better understand the security implications of an IT environment and Capture the Flag games to enhance practical security skills. To get the best results from training programs, make them interactive.
There’s potentially a long road ahead here, but the destination will be worth the effort. With DevSecOps, not only will products be secure by design, but organizations should also be able to increase the frequency of releases from quarterly to daily without increasing risk.
Featured image via Pixabay.
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.