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

CI/CD

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

Continuous Integration and Continuous Delivery (CI/CD) are practices for automating the flow from code change to running solution. Pipelines provide a standardized process for building, verification, and rollout, and reduce the risk of manual errors.

The point of CI/CD is not just speed but control. Each run should be traceable, repeatable, and have clear stopping points before anything goes to production.

The CI/CD flow from code change to production. The same artefact travels the whole way, and the stopping point before production is deliberate: every run should be traceable, repeatable and approved before it reaches end users.

Principles for CI/CD

Safe CI/CD practice is built on a few simple foundational principles:

Introduction

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

The goal of sikkerhet.bouvet.no is not to cover everything, but to give you suggestions for measures and a vocabulary that will help you move forward. All topics presented will also point to external resources that can provide even more information.

Bouvet is certified under ISO27001, which also sets requirements for security in deliveries. The checklist will provide you with a good starting point for measures that cover common security gaps and help ensure quality in the delivery. Each point in the checklist is covered by more detailed information to make it easy to get started without prior knowledge of a topic.

Roles and responsibilities

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

Bouvet conducts development projects in many different ways, where we take more or less responsibility for project management, planning, development, quality assurance, and not least the operation and management of the solution. We also involve our own, the client’s, and third-party equipment both during development and management of the solution.

Regardless of how the project is executed, it is important that we are aware of how responsibilities are divided. This should be regulated in the agreement with the client, so we must ensure that we:

Security Requirements

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

Some requirements are implicit, such as the use of HTTPS/TLS, while others will be explicit and defined by customers or third parties. Even if the customer has no specific requirements, it is still important for the delivery team to create a list of requirements to ensure that the project’s framework is documented.

Most projects must adhere to various requirements from Bouvet, the customer, and external parties. All development teams must have control over the requirements that apply to the delivery:

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.

The Security Champion Role

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

Why “Security Champion”

The term “Security Champion” has become an established concept to encompass people who do not necessarily work directly with security, but who can act as a bridge between the formal security roles and the development teams. At Bouvet we have chosen an approach inspired by NAV and Equinor, and we try to keep the whole thing as informal as possible.

What the role looks like at Bouvet

This will vary between regions, units and teams, but a typical Security Champion will raise issues and questions related to security, and help the team focus on and prioritise between security matters and everything else. The Slack channel #security-champions is used to announce events, share useful information and anything else that concerns Security Champions at Bouvet. Every month we also run what we call AppSec Caffeine, where we gather Security Champions at Bouvet for a summary of relevant news, a talk and a quiz with a symbolic prize. Registration goes through Bouvet’s own event system (requires a Bouvet login).

Verify the Design

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

When we create a design for a new solution, there may be details we do not know, or unexpected complications may arise during implementation. This can result in the original design deviating from the final solution.

Documentation is crucial for understanding how a solution is set up and how it works, especially if an incident occurs that requires redeployment or disaster recovery. To ensure that the gap between documentation and the final product is not too large, we should always validate the design afterward.

Building

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

Building is the step where source code becomes a deployable artifact. The goal is for the artifact to be reproducible, verifiable, and traceable back to a specific commit and pipeline run.

This article focuses on the building process itself. Overall pipeline management is described in CI/CD, and deployment to environments is described in Deployment.

Build environments and build agents

Build agents typically come in two main forms:

Cloud provider-managed agents
Self-hosted agents (in the cloud or on-premise)

Cloud provider-managed agents often provide lower operating costs and simpler maintenance. Self-hosted agents give you more control but full responsibility for hardening, patching, and access management.

Data and Classification

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

In short

Most organizations have different classification levels for both data and systems. The classification is often based on how data is used, where it is stored, and who can access it. This is a key requirement for any development project and must be clarified in advance.

Help build a better security community

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

At Bouvet, we hold regular gatherings - Bouvet One - where we host talks on everything under the sun, often with dedicated security tracks. We have also held specific Bouvet One events dedicated to security. Here, everyone is free to contribute - all talks are appreciated, no matter how simple you might think your topic is.

Get Involved with Regional Security Champions

Several regions in Bouvet have their own Security Champions gatherings on a regular basis, where knowledge, tips, tricks, and much more are shared. Get involved here and help build a security culture in the developer teams! We also hold regular monthly gatherings under the name AppSec Caffeine for all Security Champions at Bouvet, where we go through relevant news, talks and short quizzes.

Network Concepts

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

Correct network configuration matters in cloud, hybrid and on-prem alike. This page is meant as a short reference for secure network practice in project work.

Zero trust architecture

Zero trust means not blindly trusting internal or external traffic. Use the principle as your default: verify explicitly, grant as little access as possible, and assume compromise.

Minimum overview

Important

Keep track of which IP addresses and ports you expose, and which services are listening on those ports. Check firewall rules, look in the logs and scan your own systems with nmap.

Security Checklist

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

It’s not a given that all points are relevant for every project, or that implementing all measures is desirable. Each delivery manager must assess cost/benefit and what responsibility and risk is assumed by not introducing measures. Security requires continuous work, so review the checklist regularly to see if there are measures that can or should be introduced so that nothing is overlooked.

Download the checklist and implement it as part of the source code in your project!

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!

Business Continuity

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

Business Continuity Planning is not an IT-technical subject. But it is our responsibility as suppliers of an IT system to remind the customer that the system can become unavailable. The answer from this planning will help describe the requirements for the solution’s robustness and security level, and is crucial for finding the right balance of cost and performance for the system.

Here it is important to consider

The criticality of the solution
Possible workarounds if the solution is unavailable
Consequences or extra work resulting from unavailability or when the solution becomes available again.

Customer Expectations

Do we have a Service Level Agreement with the customer that regulates uptime, availability, and similar, or does the customer have implicit expectations for this?

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.

Deploy

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

Deployment starts after the artifact has been built and verified. The main principle is that the same artifact is promoted across environments without rebuilding in between.

This article focuses on rollout to environments. Overall pipeline management is covered in CI/CD, and details about safe artifact production in Building.

Principles for safe deployment

To reduce operational and security risk, the deployment process should be built on:

Logging and Monitoring

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

Regardless of where a solution is deployed, we should ensure that it is monitored. Even if it is only available on the intranet with only internal users working from approved devices over VPN, logging information is important if one of these is compromised. A typical DevOps team will collect some information to help debug the application’s functionality, but we also need other information to assess the security context around it.

New Employee at Bouvet?

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

As a new employee at Bouvet, there’s a lot to get familiar with. Security in our deliveries and projects is primarily handled by the delivery team – they’re the ones who know the solutions and the customer best.

Security should be part of the craft we deliver – regardless of context. As an employee, you need to understand how security affects your role and your tasks, but don’t be afraid to ask those around you or your nearest Security Champion.

Segregation of Environments

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

When we build solutions, we often set up multiple environments, typically for dev, test, and prod, so that we can develop while the product owner tests new functionality and end users use the system in prod. It is important to distinguish between these environments to avoid situations where changes in one environment affect the use of another.

When designing a new solution, we must consider how to separate the environments. For cloud services, a common approach is to use different subscriptions per environment where possible. One subscription cannot affect another unless explicitly configured, but there are other possibilities as well.

Authentication and Authorization

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

Authentication and authorization are crucial in all development projects. In short, authentication is about validating that a user represents the identity they claim to represent, typically by checking a username and corresponding password. Authorization is about checking that the user is allowed to do what they are trying to do. These are often abbreviated to authn for authentication and authz for authorization.

Authentication

When validating a user, the most important thing is to not create your own authentication solution! Ensuring that such solutions are actually secure is a huge task, and one should instead use established solutions for this!

Competence Building

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

Security is an unknown and perhaps somewhat intimidating area for many, where they don’t quite know where to start. Therefore, when a new project is initiated, it is important to assess the need for competence building among team members. Initially, this is aimed at topics related to security, but the use of new technology can also pose a risk if used incorrectly.

It is important that the team reviews the entire development process in all phases and evaluates each point against what the team knows, what is relevant for the project, and where assistance can be obtained.

Dependency Management

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

When the team is in maintenance mode, most of the issues mentioned in the article on Software Supply Chain still apply. You will encounter situations where:

A critical vulnerability is discovered in a package you use
Packages are deprecated and replaced with something new that is not directly compatible with the old
Developers behind packages stop maintaining them
Malicious actors take over a package and use it to spread malware

….and certainly other scenarios that result in you needing to do something. To ensure that packages hitting one or more of the points above are addressed, tools like Sonatype and others offer the ability to monitor various stages of the lifecycle, with the option to alert you when vulnerabilities or other events affecting quality occur.

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:

Using Artificial Intelligence

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

This page is about the use of AI in the development cycle, not the general use of AI solutions. The goal is to use AI as a productivity tool without losing control of security, quality, and traceability.

Want to learn more about AI?

Bouvet has its own portal for artificial intelligence at ai.bouvet.no, which helps you understand the technology and how it can be used in different roles. This article covers only the security side of the development cycle.

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.

Preparedness

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

An untested backup is worthless. The same applies to a disaster recovery plan that has never been tested.

If the team has done the groundwork well, you have a plan for disaster recovery that describes how infrastructure, applications, and data are restored to normal operations.

The reasons for restoration vary: human error, delivery errors, vendor failure, unavailable infrastructure, or malicious events. The goal is always the same: to reduce downtime and data loss with predictable processes.

Security Checkpoints

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

Depending on the security level a delivery aims to achieve, it may be necessary to define mechanisms for assessing security at fixed points in the development cycle, known as security checkpoints.

These can be defined between logical phases in the project, for example, between the design and development phases, or when transitioning from development to the first release in production. Other and additional checkpoints can also be defined, entirely depending on the requirements the delivery team must adhere to.

Threat Modeling

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

This is a brief introduction to threat modeling. Methods and tools are mentioned briefly, with links for further reading.

You may have already done simple threat modeling without realizing it. For example, have you ever thought about why the users of the system you’re creating need to log in with a username and password?

When these choices were made, you automatically performed simple threat modeling. You certainly don’t want unauthorized individuals to access data in your system, and you don’t want anyone to see the data transferred between your users and your website.

Contingency Plans and Incident Response

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

Many people think of security incidents as targeted attacks where someone attacks a solution by hacking it. In some cases, this may be correct, but an incident can be much more.

NSM defines a security incident as “A deviation situation where there is a potential for loss of confidentiality, integrity, and/or availability of information or ICT services. A security incident can occur as a result of a data attack, technical failure, or unintentional errors.” In other words, an incident can be almost anything that affects confidentiality, integrity, and availability. Different customers have different requirements for when to notify, escalate, and report, and to whom.

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.

System diagrams and drawings

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

When designing a solution, it’s essential to have clear and comprehensive drawings and diagrams that show the planned design. This is already done by many development teams without necessarily being a formal requirement, but it’s still worth mentioning here.

System diagrams should provide enough information to:

Validate that the implementation matches the design
Use them for threat modeling, pentesting, or similar activities
Be used by those managing the solution to get a good overview of components and data flow
Be used by the delivery team for onboarding new colleagues or handover to other teams

Although there is a lot that can be documented here, we focus on the most important aspects:

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.

Glossary

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

A

ACL Access Control List, a list that controls who has access to an object and which access rights they have.

Active Directory (AD) A directory service from Microsoft used on-premises. It manages users, groups, identities, and much more.

Artificial Intelligence (AI) A broad term for methods and systems that can perform tasks typically requiring human judgment, such as language understanding, prediction, and decision support.

AI agent A software component that uses AI models to perform tasks, often with access to tools, data, or APIs.

Content Guidelines

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

Since everything written on this site is freely available on the Internet, it’s important to follow some simple rules and guidelines for content.

Language and Style

The content on these pages is primarily for technicians, so technical language is to be expected. However, if terms are used that cannot be assumed to be well known, they must be explained. The language should be readable and understandable by most technicians, not just those who have worked with security for decades!

Changelog

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

Below are major updates rolled out to the portal. These include only significant content changes, not typos or minor adjustments.

Updates are maintained manually in data/changelog.yaml.

2026-10-27 - Design- og innholdsoppdatering

Redesign og oppdatering/oppstramming av innhold ifm lansering av nytt (foreløpig) internt initiativ knyttet til KI

2026-05-07 - Oppdateringer for KI-sikkerhet

Sjekklisten og de fleste artiklene er revidert med informasjon om sikker bruk av KI

Search Results

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