Hierarchical Colored Petri Nets for Vulnerability Detection in Software
Architectures
Maya Benabdelhafid
1
, Kamel Adi
1
, Omer Landry Nguena Timo
1
and Luigi Logrippo
1,2
1
Computer Security Research Laboratory, Universit
´
e du Qu
´
ebec en Outaouais, Gatineau, Canada
2
School of Electrical Engineering and Computer Science, University of Ottawa, Ontario, Canada
fi
Keywords:
Software Architecture, Security, Vulnerability Detection, Access Control, Hierarchical Colored Petri Nets,
HCPN, Model Checking, ASK-CTL, CPN Tools.
Abstract:
Hierarchical Colored Petri Nets (HCPNs) are a powerful formalism for modeling complex systems. This paper
presents a formal approach based on HCPN for vulnerability detection in software architecture. By incorpo-
rating model checking and the enhanced computing-timing logic of ASK-CTL queries, the proposed approach
enables rigorous security property verification. Through a case study of a hypothetical small library system,
we demonstrate how this automated process effectively identifies a critical Access Control vulnerability: a
regular user gaining unauthorized access to a function reserved for librarians.
1 INTRODUCTION
In response to the growing number of Access Con-
trol (AC) attacks, as well as other types of attacks,
a wide range of methods for vulnerability detection
have been proposed in recent years. Among the pro-
posed methods, we find the formal methods that of-
fer a rigorous approach to address cyber threats by
employing mathematically precise model-based tech-
niques. Formal models, representing software, hard-
ware, or both, contribute to ensuring system consis-
tency through rigorous formal proofs. They comple-
ment traditional testing methods, which are typically
limited to specific execution scenarios.
Within the domain of formal methods, theorem
proving relies on computer-based proofs to verify sys-
tem properties, while model checking exhaustively
ensures that a finite-state model meets specified re-
quirements (Kulik et al., 2022). Software model
checking, an automated approach for identifying de-
fects in software, transforms source programs into
models and explores their state space to detect coun-
terexamples that violate specified properties. The
presence of a counterexample indicates a vulnerabil-
ity in the source program (Zhong et al., 2023).
Recent studies have highlighted the effectiveness
of model checking as a powerful technique for ana-
lyzing security vulnerabilities (Rouland et al., 2024).
This paper is positioned within the broader context of
identifying design-level vulnerabilities with a partic-
ular emphasis on mitigating AC attacks using ASK-
CTL based model checking. It proposes a formal
framework based on Hierarchical CPN (HCPNs) for
modeling, enabling modular, maintainable design and
offering a structured approach to build secure soft-
ware architectures. HCPNs provide a formal foun-
dation that enables rigorous verification of system
properties, while their expressive primitives allow
for precise modeling of security-related interactions.
Once the architecture is modeled, we show how the
model checking technique can be employed to verify
if the model satisfies security properties formulated
in ASK-CTL formulas. Vulnerabilities (namely, AC
flows) in software architecture are modeled, enabling
early detection of security flaws before deployment.
Our work also demonstrates that, during the detec-
tion process, valuable insights can be gathered regard-
ing the instances of detected vulnerabilities, making it
possible to later integrate security patterns to mitigate
vulnerabilities.
The remainder of this paper is structured as fol-
lows: Section 2 covers preliminaries; Section 3 out-
lines the software architecture and AC challenges;
Section 4 details our HCPN-based vulnerability de-
tection approach; Section 5 reviews related work; and
Section 6 concludes with a summary and future direc-
tions.
Benabdelhafid, M., Adi, K., Timo, O. L. N. and Logrippo, L.
Hierarchical Colored Petri Nets for Vulnerability Detection in Software Architectures.
DOI: 10.5220/0013638700003979
In Proceedings of the 22nd International Conference on Security and Cryptography (SECRYPT 2025), pages 523-530
ISBN: 978-989-758-760-3; ISSN: 2184-7711
Copyright © 2025 by Paper published under CC license (CC BY-NC-ND 4.0)
523

2 PRELIMINARIES
2.1 Colored Petri Nets
CPNs allow the definition of tokens using data types
and complex data manipulations (Jensen et al., 2007).
Each token carries an associated data value, referred
to as a colored token that can be examined and mod-
ified by the transitions occurring in the model, en-
abling dynamic behavior representation.
Definition 1 (CPN syntax). A CPN is defined as a
9-tuple: CPN = (Σ, P, T, I, O, C, G, V, M
0
), where:
• Σ is a finite set of color sets, which are non-empty
types;
• P = {p
1
, p
2
, . . . , p
m
} is a finite set of places and
T = {t
1
, t
2
, . . . , t
n
} is a finite set of transitions,
such that P ∩ T =
/
0;
• I is an input function I : P × T → N that defines
directed arcs from places to transitions;
• O is an output function O : T ×P → N that defines
directed arcs from transitions to places;
• C : P → Σ is a color function that assigns a color
set to each place;
• G is a guard function G : T → Expr
Bool
such that
∀t ∈ T , Type(G(t)) = Bool and the types of vari-
ables in G(t) are subsets of Σ;
• V is a finite set of variables v ∈ V where each vari-
able has a color type c ∈ C. Arc expressions and
guards can contain such variables;
• M
0
is the initial marking function M
0
: P →
Bag(C(p)), specifying the initial distribution of
colored tokens in each place p ∈ P.
Definition 2 (CPN semantics). The semantics of a
CPN is described by a transition system called State
Space : SS = (M , M
0
, −→) :
• the configurations of M are markings M, with
M(p) ∈ Bag(C(p)) for each place p ∈ P,
• the initial configuration is the initial marking M
0
,
• the transition relation −→ is defined as follows:
Let t be a transition and let v be a valuation of
variables. We write v
−
(p, t) ∈ Bag(C(p)) and
v
+
(t, p) ∈ Bag(C(p)) for the respective values of
E(p, t) and E(t, p) for p ∈ P. The transition
M
t,v
−→ M
′
is possible if, for each place p ∈ P,
M(p) ≥ v
−
(p, t) and in this case, M
′
(p) = M(p)−
v
−
(p, t) + v
+
(t, p) for each p ∈ P.
• To fire a transition, all variables must be associ-
ated with specific colors. An execution starting
from M is a sequence of firings M
t
1
,v
1
−−→ M
1
t
2
,v
2
−−→
M
2
. . .. A marking M
′
is reachable from M if
there exists a finite execution (called Path) M
t
1
,v
1
−−→
M
1
t
2
,v
2
−−→ M
2
. . .
t
n
,v
n
−−→ M
n
starting from M such that
M
′
= M
n
.
2.2 Hierarchical Colored Petri Nets
HCPNs extend CPNs to support modular modeling
of complex systems (Jensen and Kristensen, 2009).
They use substitution transitions to encapsulate mod-
ules and port places as interfaces for token exchange.
Definition 3 (CPN module). A CPN module is a 4-
tuple: CPN
module
= (CPN, T
sub
, P
port
, PT ) , where:
• CPN = (Σ, P, T, I, O, C, G, V, M
0
) is a model with-
out hierarchical properties;
• T
sub
⊆ T represents a set of substitution transi-
tions;
• P
port
⊆ P denotes a set of port places;
• PT : P
port
→ {In, Out, In/Out} is a port-type func-
tion that assigns a type to each port place.
Definition 4 (HCPN). A HCPN is a 4-tuple: CPN
H
=
(S, SM, PS, FS) where:
• S is a finite set of CPN modules. For each
CPN
module
= (CPN, T
s
sub
, P
s
port
, PT
s
) it must sat-
isfy the requirement: (P
s1
∪ T
s1
) ∩ (P
s2
∪ T
s2
) =
/
0 ∀s
1
, s
2
∈ S such that s
1
̸= s
2
;
• SM is a submodule function T
sub
→ S that assigns
a submodule to each T
sub
⊆ T , with the require-
ment that the module hierarchy is acyclic;
• PS is a port-socket function assigning a port-
socket relation: PS(t) ⊆ P
sock
(t) × P
SM(t)
port
to
each substitution transition t ∈ T
sub
, satisfy-
ing: ST (t) = PT (p
′
), C(p) = C(p
′
), I(p)() =
I(p
′
)() ∀(p, p
′
) ∈ PS(t), ∀t ∈ T
sub
;
• FS ⊆ 2
P
is a set of nonempty fusion sets
such that: C(p) = C(p
′
) and I(p)() =
I(p
′
)() ∀(p, p
′
) ∈ f s, ∀ f s ∈ FS.
CPN Tools (Ratzer et al., 2003) is an environ-
ment for editing, simulating, and analyzing CPNs and
HCPNs, with built-in state-space exploration and an
ASK-CTL model checker.
3 SOFTWARE ARCHITECTURE
AND ACCESS CONTROL IN
WEB APPLICATIONS
AC stands out as the most critical vulnerability in
the Open Web Application Security Project (OWASP)
Top 10 - 2021 (Simplice et al., 2023).
Poorly enforced AC mechanisms expose software
systems to unauthorized access. The architecture of a
SECRYPT 2025 - 22nd International Conference on Security and Cryptography
524

web application defines how its components interact
to maintain functionality. Typically, such applications
comprise client browsers, web servers, and databases,
which communicate to enable data exchange. How-
ever, as web applications become increasingly preva-
lent for remote access, they also face increased secu-
rity threats. Exposing interactive features online in-
creases the risk of unauthorized access, making AC a
critical concern.
To illustrate these challenges, we consider a col-
lege library web application based on the OWASP
framework (OWASP, 2024). This system allows stu-
dents, staff, and librarians to search for books and
manage resources. The potential vulnerabilities in-
clude the Common Weakness Enumeration ”CWE-
285: Improper Authorization”. Authorization deter-
mines whether a user with a specific identity has the
necessary privileges to access a resource, based on de-
fined permissions and AC policies. When AC checks
are not applied consistently - or not at all - users are
able to access data or perform actions that they should
not be allowed to perform. This can lead to a wide
range of problems of improper authorization. Library
resources may be inadvertently exposed due to mis-
configured access permissions or system design flaws.
The security of such a system hinges on effective AC
enforcement. If vulnerabilities exist, attackers can by-
pass authentication, escalate privileges, or manipulate
requests, leading to data breaches. If the system fails
to validate user roles properly, a regular user may in-
advertently gain access to librarian-only resources. In
both cases, a misconfigured control leads to an unau-
thorized disclosure of resources, potentially compro-
mising the system’s security.
Let us consider a simple scenario: While reg-
ular users can log in to explore and request books
(getBooks), librarians hold administrative privileges,
including updating book records and managing user
accounts (getReqBooks). A weak AC policy could
allow an attacker posing as a student to execute
getReqBooks — intended for librarians — by craft-
ing a manipulated API request or exploiting session
vulnerabilities. This could result in unauthorized ac-
cess to the database, such as adding unauthorized
users. To go to the essence of the problem, we as-
sume that the software architecture consists of two
user roles and defines four communication ports:
• User Roles: Two main user types are defined:
Admin and RegularUser, each with specific priv-
ileges and access rights within the system.
• Communication Ports: The system regulates in-
teractions and data exchange through ports con-
necting Browser, WebServer, and Database:
– B2WPort: Browser toWebServer, handling user
requests.
– W2BPort: WebServer to Browser, delivering re-
sponses.
– W2DPort: WebServer to Database, retrieving
stored data for operations like getBooks and
getReqBooks.
– D2WPort: Database to WebServer, returning
query results.
This simplified example serves to illustrate our
formal approach.
4 VULNERABILITY DETECTION
APPROACH
Our formal approach for vulnerability detection pro-
vides a process for identifying security weaknesses
within software architectures. It begins with the man-
ual construction of a HCPN model, which captures
the system’s structure. The hierarchical nature of
HCPNs promotes modularity and scalability. Using
CPN Tools, the model’s state space is generated to
explore all possible execution paths and interactions.
Next, ASK-CTL properties are formally specified to
express security requirements, enabling thorough ver-
ification of AC and other critical security properties.
Once the specifications are defined, the verification
process can be executed.
The following subsections detail each step of this
approach.
4.1 HCPN Modeling
Based on the software architecture specified in an
semi-formal language (e.g., Unified Modeling Lan-
guage), we develop a formal model for each com-
ponent using CPN and HCPN formal specifications
given in Section 2. Notably, several studies have pro-
posed approaches to transform UML diagrams into
CPN and HCPN (Von Borstel et al., 2022), (Soares,
2017). Building on the simplified college library
Web application introduced in Section 3, our com-
plete model is manually constructed and organized
into a modular structure with two levels of abstraction
(Level 1 and Level 2).
Figure 1 depicts the overall software architec-
ture CPN
H
(a) (Level 1), and three components:
CPN
Browser
(b), CPN
Webserver
(c), and CPN
Database
(d)
(Level 2):
• Components are developed as a set of CPN mod-
ules, s ∈ S, represented by substitution transi-
tions T
sub
(rectangles in (a)) to which they are as-
Hierarchical Colored Petri Nets for Vulnerability Detection in Software Architectures
525

A1
USER
USER.all()
B
USERxOPERATION
BWConnector
PORT
PORT.all()
E
DATA
F
DATA
WDConnector
PORT
PORT.all()
C
OPERATION
D
DATA
A2
OPERATION
OPERATION.all()
Browser
BrowserBrowser
Webserver
WebserverWebserver
Database
DatabaseDatabase
(a) CPN
H
F
Out
DATA
Out
A2
In
OPERATION
OPERATION.all()
In
E
In
DATA
In
AcceptedRequest
USERxOPERATION
A1
In
USER
USER.all()
In
B
In/Out
USERxOPERATION
In/Out
CalledOperation
USERxOPERATION
BWConnector
In
PORT
PORT.all()
In
ExecuteUserRequest
List.exists (fn (user, operation) => user = u andalso operation = opp) Policies
CallOperationBW
SendBrowserRequestToW
ReceiveResponse
d
opp
d
OkBWPort(u,opp,p)
u
(u,opp)
(u,opp)
(u,opp)
p
(u,opp)
(b) CPN
Browser
ResponseQueue
OPERATION
BWConnector
In
PORT
PORT.all()
BrowserRequestReceived
USERxOPERATION
E
Out
DATA
DResponseReceived
DATA
C
In/Out
OPERATION
In/Out
WDConnector
In
PORT
In
D
In
DATA
B
In
USERxOPERATION
In
ReceiveBRequest
ProcessRequest
CallDataBase
ReceiveDatabaseResponse
SendResponseToB
opp
p
(u,opp)
OkWBPort(d,p)
(u,opp)
d
OkWDPort(opp,p)
p
opp
d
d
(u,opp)
PORT.all()
Out
In
In
(c) CPN
Webserver
WrequestReceived
OPERATION
WDConnector
In
PORT
PORT.all()
In
D
Out
DATA
Out
Operation
DATA
C
In
OPERATION
In
ReceiveWrequest
ExecuteOperation
input (opp);
output (d);
action
executeOpp(opp);
ReturnResultsToW
opp
p
opp
OkDWPort(d,p)
d
d
opp
(d) CPN
Database
Figure 1: Software architecture for the college library system : CPN
H
.
SECRYPT 2025 - 22nd International Conference on Security and Cryptography
526

signed (SM, PS functions) and composed together
to form CPN
H
,
• Library states are represented by port places P
port
(ovals in (a)) and tagged (PT function) with in-
put and/or output, used for exchanging tokens
(blue and small rectangle in (b-d)) between com-
ponents,
• Exchanged message types are encoded in the
color set of tokens Σ of the places,
• The initial marking represents the state of user
requests and communication ports. Specifi-
cally, user requests are defined as tokenized pairs
in the form USER.all(), OPERATION.all(),
structured according to the USER and OPERATION
color sets. This marking indicates that both the
Admin and RegularUser roles have submitted re-
quests for the getBooks and getReqBooks oper-
ations.
• CPN
H
defines color sets Σ and variables V :
colset USER = with Admin | RegularUser;
var u : USER;
colset OPERATION = with getBooks | getReqBooks;
var opp : OPERATION;
colset USERxOPERATION = product USER *
OPERATION;
colset DATA = STRING;
var d: DATA;
colset PORT = with B2WPort | W2BPort | W2DPort
| D2WPort;
var p: PORT;
As shown, USER color set categorizes users as ei-
ther Admin or RegularUser, while OPERATION
includes getBooks and getReqBooks. DATA
is defined as a string type. Concerning PORT,
it represents communication channels (B2WPort,
W2BPort, W2DPort, D2WPort). Composite color
sets such as OPERATION×DATA represent tuples
combining these elements.
• CPN
H
defines also different functions developed
for regulating interactions :
fun executeOpp (opp: OPERATION) =
if opp = getReqBooks then "Allbooks"
else "UserBooks";
fun OkBWPort (u: USER, opp: OPERATION, p: PORT)
= if p=B2WPort then 1‘(u,opp)
else empty
fun OkWDPort(opp:OPERATION, p:PORT)
= if p=W2DPort then 1‘opp
else empty
fun OkDWPort(d:DATA, p1:PORT)
= if p1=D2WPort then 1‘d
else empty
fun OkWBPort (d: DATA, p: PORT)
= if p=W2BPort then 1‘d
else empty
As illustrated, executeOpp returns "Allbooks"
for getReqBooks and "UserBooks" otherwise.
Additional functions (OkBWPort, OkWDPort,
OkDWPort, OkWBPort) validate data transmission
through the corresponding communication ports.
• The AC policies are also given. They define which
user roles can perform specific operations:
val basePolicies = [ (Admin, getReqBooks),
(Admin, getBooks), (RegularUser, getBooks)]
val Policies = if roleExtension then
basePolicies ++ [(RegularUser, getReqBooks)]
else basePolicies;
Each policy pairs a role u with an operation
opp. Verifying AC ensures that sensitive oper-
ations like getReqBooks are restricted to autho-
rized roles, preventing unauthorized access and
maintaining system security.
Parts (b–d) of Figure 1 detail how user requests
are processed and how policies are enforced in the
Browser (ExecuteUserRequest transition) through a
guard function G:
List.exists (fn (user, operation) => user = u
andalso operation = opp) Policies
As the software architecture is being modeled,
simulations are simultaneously conducted to ana-
lyze the behavior and identify potential inefficiencies.
These simulations enable testing of various scenar-
ios, optimizing performance, and ensuring seamless
processing of user requests across the entities. By
monitoring token flow and state transitions, we can
iteratively refine CPN
H
model. However, simulations
alone are not sufficient to identify system vulnerabili-
ties. While they help in analyzing functional correct-
ness and performance, they do not guarantee security
against potential threats such as unauthorized access.
To ensure security, verification techniques such
as model checking can be employed to detect and
mitigate vulnerabilities. For example, verifying the
CWE-285 vulnerability involves checking whether a
RegularUser is improperly allowed to perform the
getReqBooks operation. By analyzing the system’s
behavior across all possible states (state space SS),
we can confirm that unauthorized access is consis-
tently prevented, or identify any potential misconfig-
urations.
4.2 State Space Generation
Figure 2 represents the state space of CPN
H
model
that will be used for analyzing the security of the
software architecture (SS). Each node in SS corre-
sponds to a unique system state or marking M, char-
acterized by colored token distributions across places.
Hierarchical Colored Petri Nets for Vulnerability Detection in Software Architectures
527

The directed edges between nodes indicate transitions
fired by system events. The dense interconnections
between states highlight the system’s complexity by
showing multiple execution paths and potential secu-
rity vulnerabilities. This visualization enables formal
verification through SS exploration, allowing the de-
tection of security flaws, such as unauthorized access,
by checking for unexpected transitions or unreachable
states. To detect the CWE-285 vulnerability, we per-
form model-checking of the system against an ASK-
CTL property that specifies the absence of this vulner-
ability. This property refers to a safety property that
ensures a bad marking is unreachable from the initial
marking, regardless of the execution path taken in the
system’s state space. A bad marking occurs when a
token appears in an unintended or unexpected place.
Figure 2: Generated state space: SS.
4.3 ASK-CTL Based Model Checking
Figure 3 evaluates the college library web appli-
cation by verifying whether unauthorized users
can execute restricted operations using Standard
ML (SML) functions. The isAllowed function is
defined to check user permissions based on prede-
fined Policies while the AC function is used to
simulate access attempts. If a user is authorized,
the operation executes; otherwise, access is denied.
The allUserOpPairs function generates all possible
(u,opp) pairs and systematically tests them using
verify vulnerability, ensuring that unauthorized
actions are correctly blocked. If an operation intended
for librarians (e.g., getReqBooks) is executed by a
regular user, the system identifies an AC flaw, high-
lighting potential privilege escalation risks. A ‘true‘
result confirms that the operation can be executed in
violation of the policies. A model checking proce-
dure answers the following question: Given a state
ASK-CTL formula and a CPN/HCPN, does the initial
marking satisfy the formula? Different from Figure
3, which applies a predefined policy verification, the
second SML listing given in Figure 4 applies ASK-
CTL and model checking to formally verify security
properties. Instead of relying on predefined rules, it
defines logical formulas that express the AC security
property and evaluates them over the system’s state
space.
Figure 3: AC verification using SML.
Figure 4: Formal Verification Using ASK-CTL.
In ASK-CTL, path properties are described us-
ing two primary logical operators: EXIST UNTIL and
FORALL UNTIL. These fundamental operators serve as
the basis for deriving additional ones, such as POS and
EV. For our example, we focus on POS operator:
POS(M) ≡ EXIST UNTIL(T T, M)
where TT denotes a truth value. This operator returns
true if there exists at least one path from an initial
state that leads to a state where M holds true. The list-
ing uses the syntax $Mark.<SubNet>’<Place>NM$
to retrieve tokens in place <Place> of the N
th
instance
of page <SubNet> within the marking M. It then ap-
plies an ASK-CTL formula with the POS operator to
verify whether all paths avoid a given condition. A
positive result indicates the presence of a vulnerabil-
ity—specifically, a situation where an unauthorized
user gains access to a resource before the required to-
ken becomes valid, ex. a RegularUser attempting
to execute getReqBooks illustrates a potential exploit
path that could lead to unauthorized access.
5 RELATED WORK
The rigorous formalization of software architecture
models for verifying and validating system security
SECRYPT 2025 - 22nd International Conference on Security and Cryptography
528

has become a central research topic (Kulik et al.,
2022). Among the most effective approaches, model
checking stands out for its ability to exhaustively an-
alyze a system’s state space to detect potential vul-
nerabilities. By applying first-order logic and tem-
poral logic, such as CTL and Linear Temporal Logic
(LTL), model checking can enable the automatic ver-
ification of whether certain security policies hold in
a given system. For instance, in (Rouland et al.,
2024), the authors introduce a first-order logic based
method for specifying software architecture models,
detecting vulnerabilities, and identifying associated
anchor points for applying security controls. Unlike
our approach, which utilizes ASK-CTL, their paper
employs first-order logic to express structural con-
straints and the behavior of signatures forming an
Alloy model. Different from Alloy, CPNs provide
a graphical and token-based representation, making
them particularly useful for analyzing concurrent and
distributed systems. Also, HCPN model data flows
between ports by explicitly representing information
movement through tokens. They enable direct visual-
ization of asynchronous and synchronous communi-
cation and support hierarchical structuring and mes-
sage transformations, making them ideal for tracking
data interactions in software architecture.
In the literature, recent studies reveal the promis-
ing use of CPNs/HCPNs for vulnerability detection.
In (Wang et al., 2024), the authors introduce a new
concept called vulnerability nets, designed to detect
security vulnerabilities in source code. Specifically,
this approach is based on CPN and helps to identify
taint-style vulnerabilities, such as buffer overflows,
injection flaws, and cross-site scripting issues. Vul-
nerability nets can perform automated analysis, al-
though the analyst must assist in identifying saniti-
zations to minimize false positives. Also, in (Zhou
et al., 2020), the authors present a CPN-based ap-
proach for modeling and analyzing attack tolerance
in Web services, particularly in cloud environments
where service continuity is critical. Their framework
is abstract and generic and uses monitors in CPN
Tools. It focuses on formalizing attack-network in-
teractions and detection mechanisms in order to de-
velop effective tolerance solutions. Recently, in (Al-
Azzoni and Iqbal, 2024), a formal approach is intro-
duced for verifying AC in smart contracts written in
the Digital Asset Modeling Language (DAML), using
CPN and CPN Tools. The approach is model-driven
and employs a new meta-model to capture AC re-
quirements within DAML contracts. It automates the
entire verification process, from parsing the DAML
code and generating model instances to transforming
these models into CPN models and performing model
checking. On the same issue of smart contracts, in
(He et al., 2023), the authors introduce a formal ap-
proach to model and analyze smart contract secu-
rity using CPN, with a focus on detecting re-entrancy
bugs, a major vulnerability that has led to significant
financial losses. This method employs HCPN mod-
eling to represent smart contracts at the source code
level and applies formal analysis techniques, includ-
ing correlation matrices, state space reports, and state
space graphs generated via CPN Tools, to identify
potential security flaws. The research described in
(Gowdanakatte et al., 2024) is more specific in its
application area. It presents a holistic methodology
for assessing asset criticality and system resiliency in
Industrial Control Systems within the energy sector.
It utilizes CPN modeling for formal verification and
automated analysis of system behavior under cyber
attacks. Applied to a wind farm system, this work
enables state-based analysis, identifies vulnerable as-
sets, and proposes mitigation strategies. Similar to the
aforementioned contributions, our approach explores
CPNs and HCPNs for comprehensive software archi-
tecture modeling. In (Tikhonov and Novikov, 2021),
the authors use CPN and CPN Tools to dynamically
model and verify AC systems, aiming to reduce vul-
nerabilities. They highlight ASK-CTL logic for im-
proving security analysis by explicitly modeling ac-
tions and rules, a focus also explored in our work.
In (Amthor and Rabe, 2019), the authors proposed
a new heuristic approach to handle dynamic depen-
dencies, which are common in complex models such
as type enforcement mechanisms. They demonstrated
the practical impact of this analysis problem and dis-
cussed the implications of their findings for the design
and analysis of AC models.
6 CONCLUSIONS
In an era marked by increasingly complex software
architectures, ensuring robust protection against cy-
bersecurity threats remains a critical challenge in ap-
plication design. This work has presented a for-
mal framework for vulnerability detection based on
HCPNs and model checking techniques. Situated
within the broader domain of formal verification, the
proposed approach demonstrates the relevance and
effectiveness of HCPNs and model checking in per-
forming rigorous security analyses, particularly in the
context of web applications. We demonstrate how
HCPNs offer a concise yet expressive graphical no-
tation, making them accessible to both experts and
non-specialists. Supported by mature tools such as
CPN Tools, HCPNs enable efficient modeling, simu-
Hierarchical Colored Petri Nets for Vulnerability Detection in Software Architectures
529

lation, and analysis of software architectures. Their
formal semantics provide a strong foundation for rig-
orous verification of system properties, while their
rich modeling primitives facilitate precise representa-
tion of complex security interactions. Additionally,
we utilize ASK-CTL logic to formally express and
verify security properties. Through this analysis, we
identify several directions for future research. These
include enhancing policy violation detection through
counterexample generation and addressing the state
space explosion problem via optimization techniques,
aiming to support more scalable analyses. These en-
hancements will facilitate the integration of security
design patterns into system architectures, promote au-
tomated vulnerability mitigation, and reinforce re-
silience against evolving cyber threats. By bridging
formal verification with security-aware design, our
approach not only identifies vulnerabilities but also
supports the development of more robust systems.
REFERENCES
Al-Azzoni, I. and Iqbal, S. (2024). Access control verifica-
tion in smart contracts using colored petri nets. Com-
puters, 13(11):274.
Amthor, P. and Rabe, M. (2019). Command dependen-
cies in heuristic safety analysis of access control mod-
els. In International Symposium on Foundations and
Practice of Security, pages 207–224. Springer.
Gowdanakatte, S., Abdelgawad, M., and Ray, I. (2024).
Assets criticality assessment of industrial control sys-
tems: A wind farm case study. In 2024 IEEE 24th
International Conference on Software Quality, Relia-
bility and Security (QRS), pages 352–363. IEEE.
He, Y., Dong, H., Wu, H., and Duan, Q. (2023). Formal
analysis of reentrancy vulnerabilities in smart contract
based on cpn. Electronics, 12(10):2152.
Jensen, K. and Kristensen, L. M. (2009). Formal defini-
tion of hierarchical coloured petri nets. Coloured Petri
Nets: Modelling and Validation of Concurrent Sys-
tems, pages 127–149.
Jensen, K., Kristensen, L. M., and Wells, L. (2007).
Coloured petri nets and cpn tools for modelling
and validation of concurrent systems. International
Journal on Software Tools for Technology Transfer,
9(3):213–254.
Kulik, T., Dongol, B., Larsen, P. G., Macedo, H. D., Schnei-
der, S., Tran-Jørgensen, P. W., and Woodcock, J.
(2022). A survey of practical formal methods for se-
curity. Formal aspects of computing, 34(1):1–39.
OWASP (2024). Application threat modeling.
https://owasp.org/www-community/Threat\
Modeling\ Process. Accessed: 2024-03-17.
Ratzer, A. V., Wells, L., Lassen, H. M., Laursen, M.,
Qvortrup, J. F., Stissing, M. S., Westergaard, M.,
Christensen, S., and Jensen, K. (2003). Cpn tools for
editing, simulating, and analysing coloured petri nets.
In International conference on application and theory
of petri nets, pages 450–462. Springer.
Rouland, Q., Adi, K., Nguena Timo, O., and Logrippo, L.
(2024). Detecting information disclosure vulnerabil-
ity in software architectures using alloy. In 19th Inter-
national Conference on Risks and Security of Internet
and Systems (CRiSIS). Springer.
Simplice, I., Fidel, O., Kennedy, C. G., Okokpujie, K., and
Gabriel, S. (2023). Enhancing information system se-
curity: A vulnerability assessment of a web applica-
tion using owasp top 10 list. In International confer-
ence on smart computing and cyber security: strategic
foresight, security challenges and innovation, pages
385–397. Springer.
Soares, J. A. C. (2017). Automatic model transformation
from uml sequence diagrams to coloured petri nets.
Master’s thesis, Universidade do Porto (Portugal).
Tikhonov, V. and Novikov, V. (2021). Verification of ac-
cess control systems based on modeling with colored
petri nets. High-Tech Technologies in Earth Space Re-
search, 13(6):50–59.
Von Borstel, F. D., Villa-Medina, J. F., and Guti
´
errez, J.
(2022). Development of mobile robots based on wire-
less robotic components using uml and hierarchical
colored petri nets. Journal of Intelligent & Robotic
Systems, 104(4):70.
Wang, P., Liu, S., Liu, A., and Jiang, W. (2024). Detecting
security vulnerabilities with vulnerability nets. Jour-
nal of Systems and Software, 208:111902.
Zhong, W., Zhou, J.-t., and Sun, T. (2023). Concurrent
software fine-coarse-grained automatic modelling by
coloured petri nets for model checking. IET Software,
17(1):55–75.
Zhou, W., Dague, P., Liu, L., Ye, L., and Za
¨
ıdi, F. (2020). A
coloured petri nets based attack tolerance framework.
In 2020 27th Asia-Pacific Software Engineering Con-
ference (APSEC), pages 159–168. IEEE.
SECRYPT 2025 - 22nd International Conference on Security and Cryptography
530