Hello world from Colint!

It started with development...

I started my professional career as a developer, and I've always been interested in security. About 10 years ago I moved over to focus primarily on cybersecurity and secure software development. As a consultant, I worked with multiple customers. We worked with secure software development and did a substantial amount of 'white-box security tests' - typically summarizing the findings in a report with recommended solutions and mitigations to customers. Each customer typically triggered such reviews once or twice a year, as one of the final steps in a release cycle.

The increased adoption of CI/CD and DevOps made this kind of reviews less efficient. The actual security posture could look completely different the week after the report was completed. And as a conclusion based on review findings, many customers wanted to involve us earlier in the next major release cycle (the rise of 'shift left) to avoid unnecessary delays.

A lot has happened since then, and almost everyone agrees today that we need to make security a part of development. The big question isn't IF we should do security as part of development, but 'HOW'...

Security as part of agile development

Many organizations are still doing most of their security work centralized, typically pentests or white-box reviews. Very similar to traditional operations (before DevOps) or QA before agile, this is disconnected from the development lifecycle. Even the best cybersecurity experts will have limited capacity to oversee changes and risks over time. We need new ways of working to tackle our future cybersecurity challenges as the amount of software increases, and key infrastructure becomes part of the applications.

With digital transformation and the industrialization of software, cybersecurity becomes everyone’s job. The increased adoption of agile, cloud, containers, DevOps and CI/CD entirely changed the way we develop, deploy and operate software. The way we do security must change accordingly. Recent studies show that vulnerabilities found in production cost 30x compared to vulnerabilities caught earlier (typically already in requirements/architecture). It also shows that there's basically an exponential growth in cost based on time of detection. This shows why security in agile development saves both money and valuable time.

I'm not saying that pentests or white-box reviews are obsolete - it's an excellent method for identifying gaps in your developer-first security work. But as long as pentests or white-box reviews are your ONLY methods to secure software, you'll be stuck in reactive mode. As long as you develop code in reactive mode, you will always have vulnerabilities as a bi-product.

The business side got on the agile train a long time ago. QA activities and large parts of operations are already team-centric. It’s time for security to take the same path. Like with QA and DevOps, it’s not necessarily about moving people from one team to another. It’s about a culture change and new stuff to learn. Key success factors are knowledge sharing and culture adoption. We must utilize the collective intelligence to identify and mitigate cybersecurity risks continuously as part of the software development lifecycle. This is a big change for both developers and application security professionals, but it's necessary if you want to continue producing sustainable and secure software.

Why Colint?

By sharing knowledge, between developers and security professionals - as well as between development teams, we increase the coverage and quality of the security analysis performed. Shared methods and efficient ways of working will also mean increased capacity in cybersecurity for the future, and more time left for innovation.

This is what Colint is about. The knowledge sharing, the tools and ways of working that helps your organization produce sustainable and secure software. It’s about utilizing the collective intelligence in your teams to secure your software. I call it developer-first security. I don't want to take the pleasure of cybersecurity work from you. But I can help you to build and improve the skills and methods needed to make cybersecurity a part of your development lifecycle.

Security awareness training vs Contextual hands-on training

Most developers I know see continuous learning as a natural part of their work. If they should become good at security, they need some kind of awareness training. My experience from traditional security awareness training is that developers find it interesting, e.g. to learn about OWASP Top 10, examples of how vulnerabilities in their code are exploited and how these vulnerabilities are mitigated. It's based on categories of threats and about how attackers operate, rather than the context of the team's daily workflow.

I think contextual hands-on security training is a lot more efficient. Instead of e.g. talking about 'broken access control' in examples, we use the features under development (in the team) to identify flaws and security requirements related to 'broken access control' and more. The output is a list of prioritized work items that can be included in the team backlog. This teaches a way of working with security continuously instead of instances of problems. The team produce threat models describing the system which can serve as agile documentation. Security flaws can be identified before any code is written. But this methodology is not only limited to flaws, it can also pinpoint where audit logging or additional security features are needed from an operations perspective. Most importantly - developers find it interesting to work with security in the context of their development, and get a fair chance to mitigate vulnerabilities before security starts pointing fingers.

The HOW

Since you are still reading, you are probably interested in learning how to apply security practices as part of development. You already got a sneak peek of one part - the contextual hands-on security training, and how it can be used to kickstart development work within the team. But there's a lot more. I've compiled a list of security practices mapping to each phase in a DevOps eight that can be applied iteratively in a DevOps team. I will publish more material around this in upcoming posts.

Core DevOps principles in security - CAMS

Finally, I'd like to highlight for DevOps principles known as the CAMS model that are important to remember when building security into your workflow. CAMS stands for Culture, Automation, Measurement and Sharing.

Culture

When you start building security as part of development you initiate a culture change. Team members will shift from seeing security as part of their job rather than a tollgate enforced by someone else. There's no unified way of doing this. The security culture has to grow together with the rest of the DevOps culture and align with your business goals, compliance requirements and quality ambitions.

Automation

Most developers love automation. Do you have any tests that you perform manually on each code change? Probably not. Are you creating the cloud infrastructure that your application relies on manually or through scripts/templates? DevOps teams automate as much as possible, both for efficiency and quality purposes.

The same goes for security. If you rely completely on manual work, it's likely that you'll miss important security weaknesses. Infrastructure as code and automated deployments are also important when it comes to efficient disaster recovery and immutable infrastructure. Infrastructure as code and Immutable infrastructure are critical success factors in security. It reduces the need of access to triage production issues by logging in to production servers, indirectly reducing the risk of high privilege credentials falling into the wrong hands.

Even if automation is important, there are couple of things to remember:

When introducing new security tools in your CI/CD pipeline like Static Application Security Testing (SAST), start with failing silently on issues discovered. This enables you to triage and learn more about the types of issues discovered over time, without blocking your team colleagues.
Ensure that the tools you use can generate machine-readable output (JSON, XML etc)
Make sure that the tool doesn't delay your pipeline substantially. If the tools take long time to run, consider running them asynchronous with your pipeline (e.g. as nightly scans). A good rule of thumb is to avoid tools that take more than 15 mins to run.

Measurement

If you want to establish a sustainable security culture at scale, you need to measure the work performed continuously. If you find yourselves (or anybody else) doing a substantial amount of security work that is not measurable, think about how you can provide transparency in terms of issues discovered and their impact. Measurements makes security visible for all stakeholders, from team members to top management in larger organizations. It also highlights if there are teams or components where the security work got stuck.

Good security solutions are too important to keep for yourself. Try to share as much as possible of your experience with team members and other teams. In my experience this is something that developers have done for a long time. Think about how many open source libraries and how much code we are reusing to create new amazing software. About 90% of a typical application is open source code. If you created a great script for secure deployment in the cloud or a hardened container image, make sure to share with other teams that you believe need the same thing. Imagine if we could share 90% of the security work too. :)

As a final note, encourage any security professionals that you work with to share their experiences and insights in the context of your application. The collective intelligence of developers and security working together will produce a lot more sustainable security than "old-style" security tests done before a major release.

Want to learn more?

If you want to learn more or share your experience in security practices as part of development, please drop me an email at emil@colint.io. Looking for more stuff to read? Check out the links below!

Emil Kvarnhammar