DevSecOps is a core IT strategy that integrates security into development and operations processes. In other words, it means considering security at every stage of software development, from the beginning of development - writing code - to deployment and operations. It's a powerful way to improve your organization's overall security posture and deliver more secure software, but it requires a cultural shift in your organisation.
There are five main benefits of DevSecOps
Reduced security vulnerabilities: By identifying and addressing security vulnerabilities from the earliest stages of the development process, vulnerabilities can be effectively eliminated.
Faster remediation: Automated testing and deployment enables you to quickly remediate security vulnerabilities and speed up time to market, as security requirements are addressed at an ongoing stage rather than at the end of service development.
Improved compliance: Integrating regulatory requirements into the development process helps you stay compliant.
Reduced costs: Reduce the cost of security flaws and improve operational efficiency.
Increased collaboration and improved security culture: Collaboration between development, security, and operations teams can improve the security culture in your organisation.
DevSecOps can be adopted in six distinct phases
Plan and prepare: Organisationally define the goals, scope, and success criteria for DevSecOps.
Culture and process change: Transform your organisation's culture to be security-focused and integrate security into the development process.
Tool and technology selection: Select the appropriate DevSecOps tools and technologies to meet your requirements.
Automation and integration: Apply and integrate continuous integration/continuous delivery (CI/CD) pipelines, automated security testing, and security monitoring.
Measurement and reporting: Measure and report on the goals of DevSecOps.
Continuous improvement: Continuously improve the effectiveness of your processes and challenge yourself to adopt new technologies.
How hard is it to implement DevSecOps?
While many organisations see the benefits of DevSecOps and try to adopt it, they may face various challenges during the implementation process. There are five main implementation/adoption challenges.
Cultural change The biggest challenge with DevSecOps is changing the culture of the engineering organisation. Development, security, and operations teams often have different goals and priorities, and these differences need to be bridged in order to work together effectively. For a successful implementation, you need to create a culture that values security across the organisation.
Integrate processes and tools Development, security, and operations processes need to be integrated. This can be a complex task that involves integrating different tools used by different teams. If Team A is using Github Actions for their CI/CD pipeline and Team B is using Jenkins, this can be a major hurdle in integrating tools. To successfully implement DevSecOps, organisations need to ensure that their processes and tools integrate and work together seamlessly.
Lack of expertise DevSecOps requires expertise in development, security, and operations. If there are large knowledge gaps and different understanding of the goals of each team, it can be costly to successfully implement and maintain the goals of DevSecOps. This means it's important to improve the overall level of organisational security expertise.
Ongoing education and training DevSecOps requires not only continuous integration and deployment, but also ongoing education and training.Engineering organisations need to maintain their level of knowledge of DevSecOps methodologies and best practices, and engineering teams need to be provided with ongoing education and training opportunities to ensure successful implementation. There should also be ongoing sharing of established DevSecOps best practices, such as documentation. .
Measurement and reporting A method for measuring and reporting on the success of DevSecOps should be established. This will allow the engineering organisation to continuously see if DevSecOps goals are being met, and identify touchpoints to address any gaps.
Start with DevSecOps, Credential Detection First
One of the best ways to get started with DevSecOps is to start with credential detection. Credentials range from common knowledge, such as a user's username and password, to sensitive information, such as API keys and cloud credentials. It's not hard to convince your engineering organisation of the threat of credential leaks.
Credential detection is the process of scanning source code, documents, workspaces, logs, and files to identify credentials and initiate action. By starting DevSecOps with credential detection, organisations can quickly experience success in mitigating threats.
The benefits of starting DevSecOps with Credential Detection include
The difficulty of cultural change can be quickly overcome with exposed Credential actions.For security teams, convincing engineering is always a challenge. With Credential, the process is very simple. Engineering knows that usernames and passwords shouldn't be written in Postit. It's an easy sell that they shouldn't be writing credentials in source code, and that's where the DevSecOps pipeline starts.
Credential detection tools, of which Cremit is one, can be easily integrated with a wide variety of tools to create best practices by integrating them into each development's processes and various collaboration tools. The impact can also be greatly expanded. For example, you can identify threats through scanning capabilities that detect credentials in source code, and even before that, you can prevent credential exposure in repositories through pre-commit hooks (when source code is committed or uploaded). You can also easily integrate with continuous integration and deployment (CI/CD) tools through the CLI, and organisationally spread success stories that apply across all phases of pre-deployment. It also integrates with your favorite tools for collaboration, such as Confluence, Notion, and Jira, and acts like an internal, exposed Credential engineering team, raising the level of organisational security awareness beyond the development phase.
Start with Credential security training to address the lack of expertise.It is very difficult to spread the knowledge of Static Application Security Testing (SAST) tools, Dynamic Application Security Testing (DAST) tools, Web Application Firewall (WAF) tools, etc. For example, recommending the use of ORMs as a way to prevent SQL Injection and spreading the knowledge of Prepared Statements is a long and arduous task. With Cremit's credential detection capabilities, you can start with easy knowledge dissemination (e.g., usernames and passwords should be securely managed), create success stories, and start spreading expertise.
Ongoing education and training can also start with credential detection.Training on the threat of credential compromise doesn't have to be difficult. Let's take an example of an AWS Access Key compromise drill. Based on the Cremit product, we scan source code repositories (Github, GitLab) and determine the scope of the impact of exposed AWS Access Keys. As AWS credentials are typically hard-coded in source code, organisations are likely to use them for multiple services, so an automated tool is needed to determine the scope of the impact. Then deploy best practices for issuing new AWS Access Keys and integrating services like AWS KMS (or Secret Manager, etc.). This makes it easy to complete a drill that assumes an AWS Access Key has been compromised.
Measure and report to meet ongoing organisational goalsWe have a goal of zero internal breaches of Credentials, and with continuous monitoring, we can quickly approach that goal. If the initial number of credentials exposed is 100, you can reach your goal in five months by aiming to reduce it by 20 per month. You can also set incremental and challenging targets as you expand your organisation's scope (pre-commit hooks, PR, CI/CD, internal documentation), so that you can continue to document and disseminate success stories to your organisation.
DevSecOps with Cremit
Cremit services can quickly self-board DevSecOps. While tools with more complex structures may require a team of professionals, the no-development approach and easy configuration make it easy to collaborate with engineering teams.
The Cremit Ferret CLI tool, which is familiar to engineering teams and easy to deploy, is intuitive, pretty (not that it really matters), supported on many platforms, and fast. In the example below, we'll walk through an example of integrating Git's Pre Commit Hook with the Cremit CLI.
First, create or log in to an account at https://start.cremit.io. Then, access Settings > CLI and issue a key.The key is used to set labels in the CLI to distinguish where the credentials are found and is used for checking in the Secret Table, etc. The API key issued after setting labels will be used in the process below, so please copy and save it.
Once created, run the curl command or download the Cremit CLI tool from within the Cremit product. Currently, we support Apple MacOS (Intel, Silicon) and Linux (x86_64, ARM) as operating systems (OS).
Write the code below to the path below within the Git repository you are working in.
.git/hooks/pre-commit
This code will prevent further steps from proceeding (exit 1) if an active secret is found.Change the value of [YOUR-TOKEN] in the code to the key issued when setting up the labels above.
If a value containing the Secret Key is found when committing after applying, it will behave like the video below.
The records found during this process can be viewed in the Secret Table within the Cremit product.
This allows security teams to centrally monitor for Credential threats in conjunction with each code repository or local workspace and proactively block threats before they are actually deployed.
