Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Assignment Proposal
Title
Continuous Information Flow Control
Names and KTH ID
Deadline
Category
Description
Information Flow Control is a security technique that aims to enforce certain invariants in computer programs, typically to achieve confidentiality. It resorts to either static analysis or dynamic monitoring to determine whether external attackers with access to public outputs can infer anything about private inputs, either through explicit flows (e.g., printing a password to the console) or through implicit flows (e.g., only taking certain publicly-observable actions if a secret meets a given condition).
We plan to introduce this important concept, as well as analyze the advantages and disadvantages associated with it, particularly when being applied in a continuous fashion throughout a project's development lifetime. Additionally, we have previously developed an IFC static analyzer for Go programs (written in Rust) - Glowy - that we can use to provide concrete examples of what an implementation might look like and how it can be used. Finally, to tie the topic further to DevSecOps, we will highlight how one could (and should) set up CI workflows to validate that every single commit follows the security invariants under enforcement.
Relevance
As a software project rapidly grows in size and complexity, it becomes increasingly difficult for a human to consider the full ramifications of a given change, especially when it comes to the nuanced (and usually indirect) impact it can have on the security of seemingly unconnected components. Nevertheless, security is a paramount aspect to preserve at all times due to the enormous implications a single flaw can have if deployed undetected. Thus, it is critical that as many prevention techniques as possible are applied as often as possible (i.e., to every commit) in a completed automated fashion, embodying the spirit of DevOps (and, specifically, DevSecOps).