Introduction#

Goal: Show the reader why the paper is interesting and important. Give an overview of the problem statement, methodology, and summarize results. Provide a list of the paper’s contributions.
Length: 1 - 1.5 pages

A well-written introduction is vital as readers form an opinion and have certain expectations after reading it. The introduction should provide enough information to the reader about the motivation, the argument, the paper structure, and the research being conducted. It may also already give an overview of the key findings.

Don’t:

Have a vague, wrong, or disorganized introduction - it will leave a negative impression on readers.
Try to convince the reader that your research questions are hard or complicated.
Start with empty phrases like “In today’s world” or similar.

Example Structure#

Structure for an introduction of a paper in a general security area.

Zoom-in: Describe the context, then zoom in on the specific area of the research (1-2 sentences).
Hooks: These should make the reader care about the topic and want to read the paper. Recent events that relate to the research usually make good hooks (each 2-3 sentences).
Motivation: Explain why doing this research is important (1-2 paragraphs).
Problem Statement: Define the problem and how the research contributes to its solution. Clarify what is and is not within the scope of the paper (1-2 paragraphs).
Research Questions: State your research questions. Each question can be followed by a very brief explanation (2-4 questions, 1-2 sentences each).
Contribution: Point out what the paper’s contributions are. This can include high level major results or results teasers (2-3 sentences).
(Optional) Paper Structure: Give a brief overview of the following sections (1-2 sentences).
(Optional) Replication Package: Optionally, include the replication package reference to highlight it (1 sentence).

Problem Statement#

A problem statement is a common part of the introduction:

A properly articulated problem statement makes reading and understanding papers easier.
A properly articulated problem statement helps reviewers write a short overview of the paper.
It is a red flag if it is hard to write that overview correctly because the paper needs refinement.
Example: “In this work, we investigate privacy and security misconceptions by end users of cloud office applications in a user study including participants from both the U.S. and Germany. For this, we conducted two online surveys with 200 crowd workers from Amazon’s Mechanical Turk and ClickWorker. With a combination of qualitative and quantitative methods, we modeled the two surveys to explore the following research questions:” - Cloudy with a Chance of Misconceptions: Exploring Users’ Perceptions and Expectations of Security and Privacy in Cloud Office Suites

Research Questions#

LaTeX Examples#

Bold Paragraphs#

Committed RQ examle

LaTeX Code

% RQs
%% RQ1
\boldparagraph{RQ1}{\itshape ``How are Open Source Components included in companies' tech stacks in terms of position, importance, and security effects?''}
\Glspl{osc} hold an important role in many companies' software stacks.
We are interested in the specific roles of these components in the software stack, as well as if and how these components are considered in the update and security processes of the projects.
%% RQ2
\boldparagraph{RQ2}{\itshape ``What are companies' awareness, experiences, and attitudes regarding the security of including external \gls{os} code?''}
Including external \glspl{osc} in industry projects introduces unique security challenges and attack vectors such as code contributions from unvetted sources.
We are interested in companies' awareness surrounding the security of including external \gls{os} code, as well as their experiences with, and past challenges of, including external code in the context of security and updates.
We are also interested in the companies' attitudes about including, managing, and contributing back to \glspl{osp}.
%% RQ3
\boldparagraph{RQ3}{\itshape ``If and how do stakeholders make decisions and considerations around security and trust challenges of including Open Source Components?''}
The major impact of security challenges in \glspl{osc} justifies specific considerations.
We are interested in measures that companies utilize to decide on including \glspl{osc}, what decisions and considerations they have in place for the external code, and which improvements and changes stakeholders consider.

\vspace{4pt plus 2pt minus 1pt} % Same spacing as between the bold paragraphs

Description Environment#

Note the use of \; (a reduced width space in LaTeX) to reduce the gap between RQ label and actual question.

LaTeX Code

\begin{description}[style=nextline, leftmargin=0pt, labelsep=.75em, parsep=0em, itemsep=0em, topsep=.25em]
\item{\textbf{RQ1:}}\;\textit{How is vulnerability disclosure discussed and represented in academic security publications?}
Vulnerability disclosure is a common occurrence of security research.
We are interested in how disclosure processes are addressed in the published literature, including the presence, depth, and framing of such discussions.
\item{\textbf{RQ2:}}\;\textit{What challenges and obstacles do academic researchers face during vulnerability discovery and disclosure?}
Researchers' vulnerability disclosures are impacted by legal uncertainty, institutional constraints, and broken incentives.
We are interested in the types of difficulties researchers encounter in disclosing vulnerabilities, ranging from communication barriers to risks of liability or retaliation.
\item{\textbf{RQ3:}}\;\textit{What interactions exist between vulnerability disclosure and the academic publishing process, and what improvements are possible?}
Publishing timelines, review procedures, and venue-specific policies interact with disclosure efforts in complex ways.
We are interested in how these factors affect researchers' ability to disclose vulnerabilities and identify opportunities for improved coordination.
\end{description}

Custom Paragraphs#

SCA RQ examle

LaTeX Code

\myparagraph{RQ1} \textit{\RQone}
We want to understand how users interact with SCA tools.
There are two parts to this question:
(1) how the SCA tools are run and
(2) actions after receiving output from an SCA scan.
We want to investigate if and how SCA tool integrate into the software development pipeline and how frequently SCA scans are run.
% The SCA tool could instances such as a standalone application, an integration into the build pipeline, or an API call.
% Is it an automated process or something developers manually run?
We also want to understand how the SCA tool outputs are interpreted and the actions taken based on these outputs.

\myparagraph{RQ2} \textit{\RQtwo}
Our second research question is an extension to the first part of RQ1.
We want to identify challenges related to running the tools, as well as
 investigate if new challenges emerge if organizations scale the SCA process to more or larger projects.

\myparagraph{RQ3} \textit{\RQthree}
Our third research question is an extension to the second part of RQ1.
% Understanding how users resolve vulnerability alerts from an SCA tool is one of the main goals of our research.
We want to understand if there are challenges related to resolving the alerts.
Resolving issues in external code may be more complicated as the user may not have a full understanding of imported code.

\myparagraph{RQ4} \textit{\RQfour}
From the challenges and issues we identified in previous RQs, we want to identify improvements that could be made to SCA processes and tools.