There is an old saying that you can pick only two of the following traits: good, fast, and cheap. If you choose a good and fast path, it will be expensive. If you choose good and cheap, it will take time to get it delivered. Lastly, the fast and cheap selection will yield poor quality.
Over the past decade, companies have embraced DevOps methodologies, and understand the tough selection between the three traits. Tool selection is extremely important to implement a DevOps culture, although it will require more than just the perfect tool.
Successfully implementing DevOps, as a culture and practice, is predicated on automation. Efficient automation is how a company like Etsy does 50 deployments per day. This speed of development and deployment has some obvious advantages—bugs don’t live in production very long because rapid development and deployment replaces them very quickly with corrected code. You can also introduce new features quickly without having to wait for long development cycles to create a complete package. A new feature can be developed and deployed while other features are being developed alongside.
Like DevOps, DevSecOps is a culture. Security-minded companies are often the first to adopt DevSecOps methodologies, where developers work closely with security teams and bring security considerations earlier in the development life cycle — also known as “shifting left.”
In a typical (and simplified) software development process, you might have a requirements phase, followed by design/development, testing, and deployment. Shifting left means introducing security as far to the left in this software process as possible.
The security tools you use are essential to enabling and automating DevSecOps. You need to make sure you are selecting toolsets that will integrate with your existing environment, and support development from the source code repository, through the build process, testing, and deployment. These tools should also be API-enabled so that your developers can leverage them programmatically using automation.
Following are some ways that you could consider introducing security into the development process.
Adding DevSecOps in development processes
Requirements
The best place to introduce security is in the requirements phase. There are significant cost increases to fixing problems in later phases. There may be several ways of addressing
security in the requirements phase but a simple one is threat modeling and ensuring that the identified threats have mitigations in place.
Design/development
The same threats identified in the requirements should be kept in mind during the design and development phase. Designing how the product is going to operate should not introduce new threats while limiting the impact of existing threats that couldn’t be removed. Additionally, developers should always be following secure programming practices that are specific to the language they are using. Additionally, in cases where developers are expected to write test cases, they should be trained to write misuse cases and test against those so their software is more resistant to bad or malformed data being passed through functions they write.
Testing
All requirements should be addressed during testing, but specifically, any threat mitigation identified in the requirements phase should be tested to ensure the mitigation is in place and works. This is a case where misuse and boundaries should be tested. Data should be introduced that would violate the specifications to try to ensure any application failure is safe, meaning it doesn’t present an attacker with the opportunity to manipulate the program space or introduce and run code in a way that violates acceptable risk.
Deployment
The deployment phase may be one of the most critical, especially in the case of web applications or any application that is hosted in a network environment. All systems and containers that are deployed should be hardened, meaning unnecessary software or services should be removed and all access requirements reviewed and tightly controlled. The goal of deployment should always be to limit the attack surface, meaning the ability of an attacker to see any service from either the internet or within the network space controlled by the deployment team. This is also where you implement any changes based on observations from your production environment. Lastly, policy violations that exceed acceptable risk should be addressed before moving anything beyond this point.
Getting started
If you’re in an organization where security and development remain separate until applications are deployed and running in production, adopting a DevSecOps methodology can be challenging, especially when you have well-entrenched development processes. The cultural change alone could be met with resistance by your teams.
It may be easier to slowly push your way backward from the far right. While security testing is a minimum to push to production, you can steadily introduce secure programming practices and threat modeling into your workflows. It’s worth noting that security will typically require specialized staff, and you may not be able to find a single person who understands security from the perspective of all phases, so you’ll be adding additional bodies to your development team.
However, the increased investment in DevSecOps will pay off once you realize that security concerns, especially those that were not addressed earlier in the development process, are one of the driving forces behind deployment delays.
저자 소개
Ajmal Kohgadai is Principal Product Marketing Manager for Red Hat Advanced Cluster Security for Kubernetes. Prior to its acquisition by Red Hat, he was the Director of Product Marketing and Growth at StackRox, a leading Kubernetes security company.
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
오리지널 쇼
엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리
제품
- Red Hat Enterprise Linux
- Red Hat OpenShift Enterprise
- Red Hat Ansible Automation Platform
- 클라우드 서비스
- 모든 제품 보기
툴
체험, 구매 & 영업
커뮤니케이션
Red Hat 소개
Red Hat은 Linux, 클라우드, 컨테이너, 쿠버네티스 등을 포함한 글로벌 엔터프라이즈 오픈소스 솔루션 공급업체입니다. Red Hat은 코어 데이터센터에서 네트워크 엣지에 이르기까지 다양한 플랫폼과 환경에서 기업의 업무 편의성을 높여 주는 강화된 기능의 솔루션을 제공합니다.