Develop on Sikkerhet.bouvet.no - For Security Champions in Bouvet

Software Supply Chain

Mon, 01 Jan 0001 00:00:00 +0000

When we build software, we depend on a multitude of different third-party packages from ecosystems like npmjs, nuget, PyPi and similar. In CI/CD pipelines we have actions and code that carry out testing, building, deployment and the like. All of this is code and components that come from third parties, where our level of security is at the mercy of how those actors work. A weakness in a dependency can result in our project leaking data, or in code being manipulated or used for malicious purposes.

Version Control

Mon, 01 Jan 0001 00:00:00 +0000

Git is today the standard in most projects run at Bouvet, but if you end up in a project that uses something else many of the principles will still be transferable. Git itself is the version control tool that manages history and versioning, while GitHub handles the surrounding services such as CI/CD, security testing and similar. Azure DevOps offers many of the same features described below; even though GitHub is used as an example you should assume the same applies for Azure DevOps.

Source code is critical

Remember that source code is part of the project, and must be considered in relation to disaster recovery and backups!

Data Validation

Mon, 01 Jan 0001 00:00:00 +0000

Data validation is fundamental in all development projects. The goal is to ensure that data has the expected structure, content, and quality before it is used further in the system.

Incorrect or malicious data can lead to:

security vulnerabilities such as injection and XSS
functional errors and unstable operations
poor decision basis in reporting and analysis
reduced quality in AI models and evaluations

OWASP Top 10 has consistently shown that inadequate input validation is a recurring cause of serious vulnerabilities. The main rule is simple: data should be validated at the trust boundary, regardless of the source.

Security Practices

Mon, 01 Jan 0001 00:00:00 +0000

There are many different types of vulnerabilities and weaknesses to consider when developing new applications. The Open Worldwide Application Security Project (OWASP) publishes a prioritized list of common application vulnerabilities that many teams use as a practical starting point.

OWASP Top 10 is not a complete security standard, but a useful prioritization of what typically goes wrong in real-world projects.

Current points on the OWASP Top 10

As of today, the latest published version is OWASP Top 10:2025:

Development Environment, Tools, and Build Environment

Mon, 01 Jan 0001 00:00:00 +0000

The development environment and build environment are among the most important aspects of a development project. These environments are both a productivity factor and a critical part of the attack surface. Some teams develop and build locally on their own laptops, while others use dedicated development and build environments based on cloud services or on-premises development servers. Regardless of the solution, some core principles should always be in place: clear ownership, documented choices, standardized setups, and regular follow-up.

Documentation

Mon, 01 Jan 0001 00:00:00 +0000

Documentation is often deprioritized during delivery, but insufficient documentation creates real risk. Source code describes how something works, but not why certain choices were made, what threats were assessed, or what assumptions the solution depends on.

Security context that only exists in the heads of individuals is a vulnerability. Security mechanisms that are not documented risk being removed by someone who does not understand the consequences. Threat models that are not written down cannot be maintained or revised.

Secrets

Mon, 01 Jan 0001 00:00:00 +0000

Secrets in development projects are represented as connection strings, passwords, keys, certificates, and any other sensitive information we do not want others to know about.

There are many different approaches to handling these, and this has evolved as new services emerge. For cloud solutions, services like Azure Key Vault and similar have almost become standard, as these services handle multiple aspects of how to use and manage secrets.

Basic Principles for Handling Secrets

Secrets should never be hard-coded or checked into version control systems
Verify compliance by scanning the code - reject commits with secrets and rotate them immediately!
Keep track of which secrets you have and what access they provide
Limit the lifetime of secrets - no secrets should live more than a year, passwords and keys much shorter
Team members should not always have access to all secrets; elevate or provide access as needed

Secrets and AI tools

When AI tools are used in the development process, new ways for secrets to be exposed arise.

Security Testing

Mon, 01 Jan 0001 00:00:00 +0000

Security testing should always be an element of all deliveries. Many associate security testing with penetration testing, but it is much more than that. Some forms of testing can be done automatically as part of CICD, while others are more manual and typically performed against a deployed solution.

Before starting security testing, it is important to understand what it can provide you - there is no single measure that solves all security problems, and no single test method that uncovers all weaknesses. Security testing is also one of the areas that often require specific expertise for the results to be good and/or interpreted correctly.