You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
run: pushd de.uni_paderborn.swt.cards.update/target/repository/ && zip -r updatesite.zip . && popd
50
+
51
+
- name: Create Release
52
+
id: create_release
53
+
uses: actions/create-release@v1
54
+
env:
55
+
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
56
+
with:
57
+
tag_name: ${{ github.ref }}
58
+
release_name: Release ${{ github.ref }}
59
+
body: Please refer to the [CHANGELOG](./CHANGELOG.md) for more information.
60
+
draft: false
61
+
prerelease: false
62
+
- name: Upload Release Asset
63
+
id: upload-release-asset
64
+
uses: actions/upload-release-asset@v1
65
+
env:
66
+
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
67
+
with:
68
+
upload_url: ${{ steps.create_release.outputs.upload_url }} # This pulls from the CREATE RELEASE step above, referencing it's ID to get its outputs object, which include a `upload_url`. See this blog post for more info: https://jasonet.co/posts/new-features-of-github-actions/#passing-data-to-future-steps
Component-based Assumptions and Restrictions for Dataflow Specifications
3
+
4
+
We offer a domain specific language (DSL) for describing the system under investigation as well as all threat modeling relevant parts. We provide both a textual and a graphical editor for our DSL.
5
+
The system is described by a generic component-based system model consisting of components and their connections.
6
+
In addition, the security analyst can define security related restrictions and assumptions.
7
+
Restrictions express which components might be allowed to know which data.
8
+
Assumptions describe assumptions regarding the implementation of the components made during the design phase, e.g., that a specific component will never leak data containing a password in cleartext.
9
+
We also provide a static analysis that checks of the system meets all specified restriction with respect to the specified assumptions.
10
+
11
+
# Using Our Tools
12
+
13
+
As our tool suite is implemented as an eclipse plugin, it obviously relies on the eclipse IDE.
14
+
All plugins are developed and tested using eclipse 2020-03, support for other versions is not guranteed.
15
+
16
+
## Using pre-built binaries
17
+
18
+
You can use artifacts of our CI as a update site for eclipse plugins or have a look at our releases for more stable versions.
19
+
You can use `https://github.com/secure-software-engineering/cards/releases/latest/download/updatesite.zip` as an update site link to stay up to date.
20
+
21
+
## Building The Artifacts Yourself
22
+
23
+
Checkout this repository and checkout `https://git.cs.uni-paderborn.de/geismann/attackgraph.git` under `../attackgraph`.
24
+
25
+
Make sure you have Maven installed, then inside the directory `de.uni_paderborn.swt.cardsAttackgraphParent`, run `mvn clean verify` to build.
26
+
The update site will be available inside `de.uni_paderborn.swt.cards.update/target/repository/`.
27
+
28
+
# Documentation
29
+
30
+
Learn more about our concepts and tools in our [documentation section](https://github.com/secure-software-engineering/cards/blob/develop/docs/README.md)!
0 commit comments