🚀 Initialize workshop repository

Author: Pål-Magnus Slåtto

.github/SECURITY.md

@@ -0,0 +1,8 @@
+# Security notice
+This repository is intended for workshop purposes only.
+
+For demonstrating some of the benefits containerised development have there will be some security vulnerabilities introduced by design in this repository. 
+
+Always validate that your depencencies is up to date before introducing this workflow to your development workflow. 
+
+Feel free to contact the project owners with any questions regarding security in this repo. 

.github/workflows/stale.yaml

@@ -0,0 +1,32 @@
+name: 'Close stale issues and PRs'
+on:
+  schedule:
+    - cron: '0 0 * * *'
+
+jobs:
+  stale:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/stale@v6
+        with:
+          repo-token: ${{ secrets.GITHUB_TOKEN }}
+          # Staling issues and PR's
+          days-before-stale: 30
+          stale-issue-label: stale
+          stale-pr-label: stale
+          stale-issue-message: |
+            This issue has been automatically marked as stale because it has been open 30 days
+            with no activity. Remove stale label or comment or this issue will be closed in 10 days
+          stale-pr-message: |
+            This PR has been automatically marked as stale because it has been open 30 days
+            with no activity. Remove stale label or comment or this PR will be closed in 10 days
+          # Not stale if have this labels or part of milestone
+          exempt-issue-labels: bug,wip,on-hold
+          exempt-pr-labels: bug,wip,on-hold
+          exempt-all-milestones: true
+          # Close issue operations
+          # Label will be automatically removed if the issues are no longer closed nor locked.
+          days-before-close: 10
+          delete-branch: true
+          close-issue-message: This issue was automatically closed because of stale in 10 days
+          close-pr-message: This PR was automatically closed because of stale in 10 days

CHANGELOG

@@ -0,0 +1,14 @@
+# Contributions to the workshop files
+I'm thrilled that you want to contribute to the workshop files, thanks! 🥳
+
+To make it easier for you to contribute I've added some notes about what to keep in mind when contributing to this repository.
+
+## Bug and Feature requests
+The best way to report a bug or feature request on this project is to use the issues panel in the repository. Please mark the ticket with either `[BUG]` or `[FEATURE REQUEST]` in the start of the title to make it easy for maintainers to catagorise what's submitted. It's always nice to check the existing reports to see if anyone else has the same bug or request as you. If that's the case then you should rather give that ticket a upvote and follow the ticket. This helps the maintaner prioritise the tickets, resulting in you geting your requested feature or bugfix implemented faster.  
+
+## Pull requests
+By default we squash changes on the main and completed banches to keep the Git-log clean, and then make sure that the squash commit includes the Pull request number so we can go back and see in more details. 
+
+Always make sure that all tests and workflows passes whenever you've med a change. The most important thing with workshop files is that they actually work as intended for the end-users. Any changes that requires the end-user of this repository to run commands or have things installed for the files to run must be updated in the README.md of the relevant project. 
+
+All pull requests on the application code should be opened against main, and then be rebased down to completed after merge. All changes regarding the devcontainer configs should be opened agains the completed branch.

CONTRIBUTING.md

@@ -0,0 +1,46 @@
+# Example files for Development Containers
+**Welcome to the workshop files for working with development containers!👋🏻**
+
+This repository was created for [Security Champions Norway's meetup #3](https://sikkerhet.bouvet.no/security_champion/meetup_scnorge_3/) at Bouvet, and the keynote `Cloud Development: Secure your endpoints with containerised development environments`.
+
+If you find this repository valuable, feel free to give it a star ⭐️
+
+This project is structured with the main branch containing four different example applications in different languages (C#, Java, Typescript & Python) exposing a web server. On the branch `complete` you will find the same files, but now with a config for running development containers for the different applications. If you want to contribute to these files or want examples for other languages, please have a look at [CONTRIBUTING.md](CONTRIBUTING.md)
+
+## What is Develpoment Containers?
+A Development Container (or Dev Container for short) allows you to use a container as a full-featured development environment. It can be used to run an application, to separate tools, libraries, or runtimes needed for working with a codebase, and to aid in continuous integration and testing. Dev containers can be run locally or remotely, in a private or public cloud.
+
+One of the big benefits with development containers is that your work environment will work the same way both on Github Codespaces, as well as locally on your machine. This makes it possible to work on the Codespaces (online) by default, but also having the workspace locally if you need to work offline. 
+
+For development containers to work you would need to have a `.devcontainer` folder in your repository with a `devcontainer.json` file. To see the definition of the json file, navigate to the [documentation](https://github.com/microsoft/vscode-dev-containers/tree/main/containers) for development containers. 
+
+## Local development with containers
+In this workshop we'll use Virtual Studio Code as our editor for working with the development containers. For this to work, you will have to download the VSCode [Dev Containers](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers) plugin. 
+
+This will help you spin up repositories with existing configs, and even better - help you configure new repositories with a step-by-step guide. 
+
+Note that you need to have Docker installed locally as the plugin utilises this under the hood.
+
+## Using Github Codespaces
+If you want to use Github Codespaces you first of all need to configure your repository with a Codespace. For guides on how you can configure this, please the the [official documentation](https://docs.github.com/en/codespaces/developing-in-codespaces/creating-a-codespace-for-a-repository).
+
+A Github Codespace is a development environment that’s hosted in the cloud. Codespaces run on a variety of VM-based compute options hosted by GitHub.com, which you can configure from 2 core machines up to 32 core machines. You can connect to your codespaces from the browser or locally using Visual Studio Code.
+
+## Security in Development Containers
+Using development containers also opens up for some pretty nice features when it comes to security. In your traditional local development you install some local dependencies to make applications work, mix it with some application dependencies and suddenly you have a lot of installed artifacts that all can introduce security vulnerabilities. Some developers may also contribute on open source projects as well, introducing unknown application dependencies to be installed on your corporate device. 
+
+When using development containers you can scan and maintain your development environment with the same tools as you would with your application containers. Combine this with a CI/CD workflow and Snyk you can get build and vulnerability reports whenever there is a pull request that introduces new dependencies into the development environment, or you can run it periodically. To take it one step further you can also combine your development containers with tools like dependabot and get automated pull request against your development environment, as well as your application whenever there is a security update or a new version of a dependency.   
+
+## Working with external resources
+When working with development containers you can configure some atributes regarding port forwarding. Port forwarding is nessesary from your container to communicate with the ports your application exposes. One of the option in the `devcontainer.json` file is to automatically expose all ports from the container to the local host. When working with secure development we tend to not do this but rather define what port we need exposed. One of the big benefits with this is that you can have a QA or staging connection open on your local machine to a DB, but your development environment can't reach it as the port isn't exposed. This can be of great value if you forget that you have an open connection on a default port, say 5432 for PostgeSQL, so that a DB migration set to run on application boot dosen't modify the database unintentionally. 
+
+Another great feature with development containers is that you can install the dependencies and CLI's you would need to develop the application without it having to conflict with existing versions on your local machine. Let's say that you're working with an application running on AWS, then you can install the exact version of the CLI that's needed for that application. You can then also choose to define some configurations for the CLI, so say that your organisation have adopted the multi-account best practices from AWS, you can then have a dedicated container configured with AWS config for that account without it affecting your local configuration of the CLI.  
+
+Another feature that's worth highlighting is the benefits of working with secrets in the development containers. Say that your team has adopted a secrets manager like Vault or AWS Secrets Manager to store environment variables for your application, and that this is the case for all environments - including local development. You can then either combine this with the point above regarding CLI's configured to dedicated environments, or you can utilise the sections in `devcontainer.json` that allows you to run scripts on either the local machine or the remote container. This way the application can have the same configuration across environments without the need for multiple environment files, but your configuration file for the container has defined what the environment should be. 
+
+
+## Guides and Documentation
+- [Official docs for Development Containers](https://containers.dev/)
+- [Github Org. for Development Containers](https://github.com/devcontainers)
+- [Starter Template for Develpoment Containers](https://github.com/devcontainers/template-starter)
+- [Security Champions Norway](https://securitychampions.no/)

README.md

@@ -0,0 +1,37 @@
+*.swp
+*.*~
+project.lock.json
+.DS_Store
+*.pyc
+nupkg/
+
+# Visual Studio Code
+.vscode
+
+# Rider
+.idea
+
+# User-specific files
+*.suo
+*.user
+*.userosscache
+*.sln.docstates
+
+# Build results
+[Dd]ebug/
+[Dd]ebugPublic/
+[Rr]elease/
+[Rr]eleases/
+x64/
+x86/
+build/
+bld/
+[Bb]in/
+[Oo]bj/
+[Oo]ut/
+msbuild.log
+msbuild.err
+msbuild.wrn
+
+# Visual Studio 2015
+.vs/

dotnet/.gitignore

@@ -0,0 +1,12 @@
+namespace dotnet;
+
+public class WeatherForecast
+{
+    public DateOnly Date { get; set; }
+
+    public int TemperatureC { get; set; }
+
+    public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);
+
+    public string? Summary { get; set; }
+}

dotnet/Classes/WeatherForecast.cs

@@ -0,0 +1,21 @@
+using Microsoft.AspNetCore.Mvc;
+
+namespace dotnet.Controllers;
+
+[ApiController]
+[Route("[controller]")]
+public class SecurityChampionsController : ControllerBase
+{
+    private readonly ILogger<SecurityChampionsController> _logger;
+
+    public SecurityChampionsController(ILogger<SecurityChampionsController> logger)
+    {
+        _logger = logger;
+    }
+
+    [HttpGet(Name = "GetSecurityChampions")]
+    public string Get()
+    {
+        return "Hello Security Champions meetup 3!👋🏻";
+    }
+}

dotnet/Controllers/SecurityChampionsController.cs

@@ -0,0 +1,32 @@
+using Microsoft.AspNetCore.Mvc;
+
+namespace dotnet.Controllers;
+
+[ApiController]
+[Route("[controller]")]
+public class WeatherForecastController : ControllerBase
+{
+    private static readonly string[] Summaries = new[]
+    {
+        "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
+    };
+
+    private readonly ILogger<WeatherForecastController> _logger;
+
+    public WeatherForecastController(ILogger<WeatherForecastController> logger)
+    {
+        _logger = logger;
+    }
+
+    [HttpGet(Name = "GetWeatherForecast")]
+    public IEnumerable<WeatherForecast> Get()
+    {
+        return Enumerable.Range(1, 5).Select(index => new WeatherForecast
+        {
+            Date = DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
+            TemperatureC = Random.Shared.Next(-20, 55),
+            Summary = Summaries[Random.Shared.Next(Summaries.Length)]
+        })
+        .ToArray();
+    }
+}

dotnet/Controllers/WeatherForecastController.cs

@@ -0,0 +1,25 @@
+var builder = WebApplication.CreateBuilder(args);
+
+// Add services to the container.
+
+builder.Services.AddControllers();
+// Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
+builder.Services.AddEndpointsApiExplorer();
+builder.Services.AddSwaggerGen();
+
+var app = builder.Build();
+
+// Configure the HTTP request pipeline.
+if (app.Environment.IsDevelopment())
+{
+    app.UseSwagger();
+    app.UseSwaggerUI();
+}
+
+app.UseHttpsRedirection();
+
+app.UseAuthorization();
+
+app.MapControllers();
+
+app.Run();