NA SSDL Overview

Lexmark Secure Software
Development Lifecycle
June 2023
23WWM12325
Index—Lexmark Secure Software Development Lifecycle
Index—Lexmark
Introduction Secure Software Development Lifecycle 3
Overview
Introduction 3
Introduction
Lexmark Security Training 43
Overview
Introduction 3
Overview
Security Awareness 43
Lexmark Security
Overview Training 3
Lexmark Security Training and Design
Engineering 4
4
Security
Lexmark Security
Introduction Awareness
Training 43
Security Awareness
Secure Coding Practices 4
4
Security
Overview Engineering
Awareness and Design 43
SecurityModeling
Threat Engineering and Design 4
4
Secure
Security
Lexmark Coding
Security Practices
Engineering
Training and Design 4
4
Secure
Security Coding
TestingPractices
and Assurance 45
Threat
Security Modeling
Secure Coding Practices
Awareness 4
4
Threat
Product Modeling
Planning and Design Practices 4
Security
Threat Testing
Modeling and Assurance
Security Engineering and Design 4
45
Security
Security Testing and Assurance
Requirements Definition 5
5
Product Planning
Security
Secure andPractices
Testing
Coding Design Practices
and Assurance 45
Product Planning and Gates/Bug
Quality Design Practices
Bars 5
5
Security
Product Planning
Threat Requirements Definition
and Design Practices
Modeling 45
SecurityAdditional
Requirements Definition
Security Practices 65
SecurityQuality
Security TestingGates/Bug
Requirements Bars
Definition
and Assurance 5
5
Quality
Design Additional Gates/Bug
Requirements Bars
Definition 5
Quality
Product Planning Security
and Gates/Bug
Design Practices
Bars
Practices 65
5
Additional
Threat Security
Modeling Practices 6
6
Design Additional
Security Requirements
Security Practices
Definition 65
Design Attack
Requirements
Surface Definition
Analysis/Reduction 6
6
Design Threat
Quality Modeling
Gates/Bug Bars 65
Implementation Threat Modeling
Practices 67
Attack
Threat Surface
Modeling
Additional Analysis/Reduction
Security Practices 6
6
Attack Surface
Use of approved tools Analysis/Reduction
and code functions 67
Implementation Practices
Attack Surface Analysis/Reduction
Design Requirements Definition 6
6
Implementation
Static Practices 7
Use ofApplication
Implementation approved
Threat
Security
tools
Practices
Modeling and Testing (SAST)
code functions 6
7
7
Use
Software of approved
QA/Test tools
Practices and code functions
(verification) 7
7
Static
Use ofApplication
approved Security
tools
Attack Surface and Testing (SAST)
code functions
Analysis/Reduction 67
Static Application
Source
Dynamic Code Security
Analysis
Application Testing
Security Test (SAST)
(DAST) 7
77
8
Software QA/Test
Static
Application
Practices (verification)
Security Testing (SAST) 7
Software
Fuzz
SASTQA/Test
Testing
Tools Practices (verification) 7
77
Dynamic
Software
UseQA/Test Application
toolsSecurity
Practices
of approved Test
(verification)
and code (DAST)
functions 87
Dynamic Application
Automated Testing Security Test (DAST) 8
8
Fuzz
SCA
Static Testing
Tools
Dynamic Application
Application Security
Security Test (DAST)
Testing (SAST) 87
Fuzz Testing
SourceAutomated
Code Controls 8
Fuzz
Software QA/Test Testing
TestingPractices (verification) 8
87
Automated
Release Practices Testing 8
9
Source Code
Automated
Dynamic Controls
Testing Security Test (DAST)
Application 8
9
8
SourceApplication
Code ControlsPenetration Testing 8
9
Release
Source Practices
Code
Fuzz Controls
Testing 8
8
Release Practices
Release Security Review Testing 109
Application
Release Practices
Automated Penetration
Testing 9
9
8
Application
Incident Response Penetration
Process Testing 9
Release
SourceApplicationSecurity
Code Controls Review Testing
Penetration 109
8
9
Release
Conclusion Security Review 10
11
Incident
Release Response
Release
Practices Process
Security Review 10
109
Incident Response Process 10
Conclusion
Incident Response Penetration
Application Process Testing 11
10
109
Conclusion 11
Conclusion
Release Security Review 11
11
10
Incident Response Process 11
10
Conclusion 12
11
23WWM12325
lexmark.com 2
lexmark.com 2
lexmark.com 2
lexmark.com 2
Introduction
Lexmark is a global technology company that creates enterprise software, hardware and
services to help organizations draw deeper value from their business information and serves
customers in 170 countries. This document describes Lexmark’s process for developing
products, both software and hardware, that are more secure and better able to meet the
security requirements of our customers. It provides a description of a generally applicable
security assurance process for the improvement of software security that has been modeled
after current industry best practices.
Overview
Lexmark’s Secure Software Development Lifecycle process consists of a series of product
activities designed to address various aspects of security related to the software development
process from Planning through the Design and Implementation phases and finally through
Quality Assurance, Release and Maintenance. These activities are illustrated in the diagram
and are described in detail in the following sections.
e Prod
nanc uct
Pla
e
nt
ai nn
in
M
g
Security
nt e Re
ns q
Se ire
sp e
Re cid
cu men
u
o
In
rit
Product Release
Produ
ts
ct Design
Requirem sign
Secure D
Re l e a s e
e
en
ts
Ve
r n
ifi
ca ti o
ti o n e nt a
I m ple m
Qu
n
al
tio
y
ta
it
As
su en
ra
n le m
ce / mp
Test ct I
Produ
23WWM12325
lexmark.com 3
Lexmark Secure Software Development Lifecycle
While most of the security practices are generally applicable to all Lexmark software and
hardware, Lexmark evaluates each software/hardware product with respect to the most
applicable and appropriate security practices for that product or product class based
on actors including but not limited to target market, product maturity, and target user
environment.
Lexmark Security Training

Lexmark provides numerous avenues for security-related training that is available to all
employees of the company, regardless of role. Furthermore, security training is mandatory for
all employees involved in the planning, design, engineering and testing of any Lexmark product.
This includes program managers, software architects, code developers, and quality assurance
staff. It is also required at least biennially for current employees and is part of the on-boarding
process for new employees in these roles.
Lexmark’s security training curriculum includes courses with associated assessment tests
covering many aspects of secure software development. The training system tracks completion
status and test scores, ensuring Lexmark’s developers are aware of and in compliance with
current security best practices.
Security Awareness
Basic security awareness training is mandatory for all Lexmark product research and
development staff. Topics covered by this training include but are not limited to:
} Fundamentals of Application Security
} Software Security Awareness
Security Engineering and Design
Training in the area of security engineering design is required for domain leads, developers,
quality assurance, and project/product managers as applicable to their specific roles. Topics
covered by this training include but are not limited to:
} Creating application security design requirements
} Performing a security code review
Secure Coding Practices
Training in the area of secure coding is required for all Lexmark software developers as it
applies to the particular language or product component area of expertise. Topics covered by
this training include but are not limited to:
} Fundamentals of secure development
} Input and output validation
Threat Modeling
Threat modeling training is required for developers, quality assurance, and project/product
managers, as applicable to their specific roles. Topics covered by this training include but are
not limited to:
} Creating an Application Security Threat Model

23WWM12325
} Attack Surface Analysis and Reduction
lexmark.com 4
In addition to the available eLearning training related to threat modeling, Lexmark has a
series of recorded on-site education sessions from a third-party software security expert
that demonstrates the threat modeling process as it is applied to specific Lexmark software
products.
Security Testing and Assurance
Training in the area of security testing is required for all Lexmark software developers and
quality assurance staff as it applies to their particular product component area of expertise.
Topics covered by this training include but are not limited to:
} Fundamentals of Security Testing
} Application Penetration Testing
Product Planning and Design Practices

While the consideration of security and privacy-related issues and tasks is important during all
phases of the development cycle, it is generally most effective when security requirements are
defined at the start of the process during the initial planning and design phases. Waiting to
address security during the later stages of the development cycle can potentially be expensive
in both development time and cost. Irrespective of the type of project development cycle being
initiated (e.g., new products vs. a new underlying feature for a current product), it is important
to thoroughly analyze, define, and document the security requirements before starting the
implementation phase of the development cycle.
Security Requirements Definition
During the planning phase of each Lexmark software development project, the project is
analyzed and the security requirements for the project are determined. Specific security
requirements can differ for a particular project (product or feature) depending on the type
of software development project being initiated and the target market for the product. For
example, a product being designed to process personally identifiable health information can
have a vastly different set of security and security feature requirements (HIPAA and HITRUST)
than a product being designed to process other types of information.
Lexmark’s development architects and security staff determine these criteria by leveraging
applicable industry and government standards such as:
} OWASP Application Security Verification Standard (ASVS)
} SANS Securing Web Application [SWAT] Checklist
} CWE/SANS Top 25 (non-web applications)
} Application Security and Development Security Technical Implementation Guide (STIG)
Lexmark software teams use the set of industry standards and best practices that is most
applicable to the type of software/firmware as well as the type of product/feature being
developed to determine the security requirements for the project.
Quality Gates/Bug Bars
Another planning phase security practice that every Lexmark software development project
performs is the definition and documentation of the minimum acceptable level of security for
the project from a “quality” perspective, establishing a threshold for the types of security issues
23WWM12325
lexmark.com 5
that must be addressed and at what stage of the development cycle. This includes how security
issues found during the implementation phase of the development cycle (either by developers
or various testing tools) are ranked and classified in the bug tracking system.
Generally, the quality gates and release criteria with respect to security issues are consistent
across all Lexmark software development teams. However, there may be slight variations in
the ranking and classification based on the type of development project. An example of this
may be that a server-side software development project may have a higher-ranking process for
issues affecting stability than a client-side software project.
Additional Security Practices
The security requirements definition stage of the software development project is also when
the Lexmark development architects and security staff define the “level” of security verification
and documentation required for the particular project. This can include additional design
reviews, additional security testing, or external expert review or testing as deemed necessary.
Design Requirements Definition
During the design phase of the development cycle, Lexmark’s development architects
and security staff leverage the security requirements defined in the planning phase of the
development cycle and distill specific security design specifications. These specifications detail
security feature requirements such as authentication or encryption and determine potential
security risks and vulnerabilities that need to be addressed in the design. This may include the
creation of a formal threat model to identify potential threats that could lead to a compromise
of the product.
Threat Modeling
A formal threat modeling process is used for all Lexmark software products whose security
requirements definition indicates an operational environment where there may be a meaningful
security risk. The process identifies potential threats that could compromise the product being
developed, or potential threats that might be used as a launch point to compromise other
components or systems that interact with the product. The threat modeling exercise includes:
} System decomposition that identifies the actors, processes, data flows, data stores, and
trust boundaries
} Identification of the critical assets
} Identification of potential threats to those assets
} Determining the impact for each threat identified
} Determining the probability (risk) of compromise by an attacker
} Ranking of the risks
} Determining mitigating countermeasures as needed
A result of the formal threat modeling exercise is that it helps Lexmark’s architects and
developers define each product’s attack surface (the areas of the product where it can be
compromised).
Attack Surface Analysis/Reduction
Closely aligned with the threat modeling exercise is attack surface analysis and reduction. This
practice is a means of reducing the risk of compromise by blocking, or reducing, an attacker’s
23WWM12325
opportunity to exploit a weakness via mechanisms that aren’t necessarily related to the
lexmark.com 6
Lexmark
Lexmark Secure
Secure Software
Software Development
Lifecycle
design,
design, but
but may
may leverage
leverage other
other system
system or
or environment
environment capabilities.
capabilities. For
For example:
example: Data
Data being
being
transmitted
transmitted over
over a
a network
network is
is at
at risk
risk of
of being
being exposed
exposed to
to an
an attacker
attacker with
with a
a network
network sniffer.
sniffer.
That
That attack
attack surface
surface can
can be
be reduced/eliminated
reduced/eliminated by
by using
using an
an encrypted
encrypted channel
channel to
to transmit
transmit
network
network traffic
traffic as
as opposed
opposed to
to encrypting
encrypting the
the data
data at
at the
the sender
sender and
and having
having to
to design
design a
a key
key
management
management system
system to
to allow
allow the
the receiver
receiver to
to decrypt
decrypt the
the data.
data.
Implementation
Practices
During
During the
the implementation
implementation phase
phase of
of each
each Lexmark
Lexmark software
software development
development project,
project, care
care is
is taken
taken
that
that the
the implementation
implementation practices
practices and
and processes
processes leverage
leverage the
the appropriate
appropriate security-related
security-related
configurations
configurations and
and analysis
analysis tools
tools during
during the
the software
software build
build pipeline
pipeline process.
process.
Use
Use of
of approved
approved tools
tools and
and code
code functions
functions
For
For new-product
new-product development
development activities,
activities, Lexmark’s
Lexmark’s development/build
development/build pipeline
pipeline uses
uses the
the
most
most current
current versions
versions of
of various
various compilers
compilers and
and tools
tools for
for the
the development
development environment
environment best
best
suited
suited to
to each
each product’s
product’s requirements.
requirements. The
The build
build process
process includes,
includes, where
where available,
available, checksto
checksto
ensure
ensure that
that appropriate
appropriate compiler/linker
compiler/linker options
options and
and warnings
warnings are
are enabled
enabled and
and reports
reports are
are
reviewed
reviewed for
for security-related
security-related issues.
issues. For
For forward-compatibility
forward-compatibility reasons,
reasons, Lexmark
Lexmark also
also maintains
maintains
earlier
earlier versions
versions of
of various
various compilers
compilers and
and tools
tools for
for use
use during
during the
the maintenance
maintenance phase
phase of
of the
the
development
development process.
process.
Lexmark’s
Lexmark’s development/build
development/build process
process also
also contains
contains checks
checks for
for deprecated
deprecated code
code functions
functions and
and
routines
routines and
and issues
issues warnings
warnings when
when they
they are
are used.
used.
Static
Static Application
Source Application Security
Security Testing
Code Analysis Testing (SAST)
(SAST)
Lexmark’s
Lexmark’s software
software product
product development
development process
process includes
includes static
static analysis
analysis of
of the
the source
source code,
code,
Lexmark software product development process uses the appropriate code scanning tools for the
where
where appropriate
securityappropriate tools
tools for
analysis of source for that
that
code, language
language
where are
are available.
available.
the results Alternatively,
Alternatively,
are assessed compiled
compiled
for any security “binary”
“binary”
risks. code
code
Scanning
scanning
scanning
occurs on tools
atools can
can be
be used
continuous used
basisto
to
asscan
scan
partfor
security-related
of the defects.
defects. This
Lexmark development This
buildscanning
scanning
pipeline is
is usually
butusually done
done
can also be
as
as part
part of
of the
the Lexmark
Lexmark development
development build
build pipeline,
pipeline, but
but the
the scanning
scanning tools
tools
used separately as part of an audit or during the final security review process.can
can also
also be
be used
used
separately
separately as
as part
part of
of an
an auditing
auditing or
or final
final security
security review
review process.
process.
In
Thesupport
The most of this used
most widely
widely effort, Lexmark
used static
static licenses
analysis
analysis multiple
tools
tools types Lexmark’s
throughout
throughout of widely used
Lexmark’s and industry-leading
software
development teams3rd-
teams
party
are code
are the
the scanning
Coverity®
Coverity® tools,code
source
source that include:
code scanning
scanning tool
tool and
and the
the Veracode
Veracode binary
binary code
code scanning
scanning tool,
tool,
though
though other
other task-specific
task-specific static
static analysis
analysis tools
tools may
may bebe used
used when
when appropriate.
appropriate.
} Scanning against in-house developed code, otherwise known as Static Application Security
Lexmark
Lexmark has
has also
also integrated
integrated Black
Black Duck
Duck OpsSight
OpsSight into
into our
our build
build procedures
procedures toto validate
validate open
open
Testing (SAST)
source
source and
and license
license usage
usage of
of components
components within
within our
our firmware
firmware and
and security.
security. This
This tool
tool helps
helps us
us
Scanning
}inventory
inventory our against
our software 3rd-party
software usage
usage andcode
and beacquired
be aware
aware of through
of any the
any updates Open Source
updates required
required by Development
by updates.
updates.
Community, otherwise known as Software Composition Analysis (SCA)
Security-related
Security-related issues
issues found
found from
from these
these scans
scans are
are evaluated
evaluated by
by the
the architects
architects and
and developers
developers
}andScanning
and are against
are ranked
ranked and compiled
and classified “binary”
classified per
per the code
the quality
quality requirements
requirements defined
defined during
during the
the planning
planning phase
phase
of
of the
the development
development cycle.
cycle.
SAST Tools
Any
Any security-related
security-related issues
issues that
that map
map to
to the
the OWASP
OWASP Top
Top 10
10 are
are fixed
fixed and
and verified
verified before
before the
the
Within
}release
release in-house
phase
phase per developed
per the
the project’scode,
project’s SAST
quality
quality Tools
and
and bug are
bar used
bug bar to detect security vulnerabilities, such
requirements.
requirements.
as, memory leaks, buffer overruns, and other secure programming best practice issues.
}Software
Software QA/Test
QA/Test
At the conclusion Practices
Practices
of the (verification)
(verification)
process, a report is generated that includes the risk type and
severity
While
While rating
quality
quality for each
assurance
assurance issue.
and
and system
system testing
testing are
are a
a continuous
continuous part
part of
of Lexmark’s
Lexmark’s normal
normal
software
development process
process and
and are
are performed
performed throughout
throughout the
the design
design and
and implementation
implementation
phases
phases of
of the
the development
development project,
project, some
some types
types of
of products
products can
can require
require additional
additional security-
security-
related
related verification
verification nearer
nearer to
to the
the end
end of
of the
the development
development cycle.
cycle. Such
Such products
products are
are those
those that
that
23WWM12325
contain
contain independent
independent subsystems
subsystems that
that are
are independently
independently developed
developed and
and tested
tested and
and then
then
lexmark.com 77
Static Application Security Testing (SAST)
Lexmark’s software product development process includes static analysis of the source code,
Lexmark Secure Software tools
where appropriate Development Lifecycle
for that language are available. Alternatively, compiled “binary” code
scanning tools can be used to scan for security-related defects. This scanning is usually done
as partTools
design,
SCA of
butthe Lexmark
may development
leverage build
other system pipeline, but capabilities.
or environment the scanningFor
tools can also
example: be used
Data being
separately
transmittedas part
over a of
} Within open-source ancode,
auditing
network is at
SCA or
risk final security
of being
Tools are review
exposed
used toprocess.
anknown
to detect attacker with avulnerabilities
security network sniffer.
that are
Thatreported
attack surface
as CVEscan be reduced/eliminated by using an encrypted channel to transmit
The most widely used (Common Vulnerability
static analysis Enumeration).
tools throughout Lexmark’s software development teams
network traffic as opposed to encrypting the data at the sender and having to design a key
are the Coverity® source code scanning tool and the Veracode
} The tool will provide a report that includes the CVSS score (risk binary codeand
rating) scanning tool,
recommendations
management system to allow the receiver to decrypt the data.
though other task-specific
for component upgradesstatic analysis
for each tools may
respective CVE.be used when appropriate.
Lexmark has also integrated Black Duck OpsSight

software into our build procedures to validate open
Implementation
} This information Practices
is used to inventory component usage and track available
source and license usage of components within our firmware and security. This tool helps us
upgrades.
During the implementation phase of each Lexmark software development project, care is taken
inventory our software usage and be aware of any updates required by updates.
Security-related
that issues found
the implementation from code
practices scans are evaluated
and processes by appropriate
leverage the architects and developers and
security-related
Security-related
classified based issues found
on analysis from
the quality these scans
requirements are evaluated by the architects
phase and developers
configurations and tools during the defined
softwareduring
buildthe planning
pipeline process. of the development
and are ranked and classified per the quality requirements defined during the planning phase
cycle.
of the development cycle.
Use of approved tools and code functions
For example,
Any any security-related
security-related issues
issues that map thatOWASP
to the map toTop
the OWASP Top 10
10 are fixed andare evaluated
verified forthe
before risk and
For new-product development activities, Lexmark’s development/build pipeline uses the
any fixes are verified before the release phase per the project’s
release phase per the project’s quality and bug bar requirements. quality and bug bar requirements.
most current versions of various compilers and tools for the development environment best
suited to each product’s requirements. The build process includes, where available, checksto
Software QA/Test Practices (verification)
ensure that appropriate compiler/linker options and warnings are enabled and reports are
While quality
reviewed assurance and system
for security-related issues. testing are a continuous part
For forward-compatibility of Lexmark’s
reasons, Lexmarknormal
also maintains
earlier versions process
of various and are
compilers andperformed throughout
tools for use the
during the design and implementation
maintenance phase of the
phases of the process.
development development project, some types of products can require additional security-
Lexmark
Lexmark Secure
Secure Software Development Lifecycle
relatedSoftware
verification Development
nearer to the end Lifecycle
of the development cycle. Such products are those that
Lexmark’s development/build process also contains checks for deprecated code functions and
contain independent subsystems that are independently developed and tested and then
routines and issues warnings when they are used.
integrated into
integrated into a
a final
final complete
complete system
system (e.g.,
(e.g., printers
printers and
and multifunction
multifunction products).
products). For
For these
these
lexmark.com
types of
types of systems,
systems, security
security related
verification testing
testing practices
practices such
such as
as dynamic,
dynamic, run-time
run-time 7
Static Application Security Testing (SAST)
analysis tools
analysis tools and
and targeted
targeted fuzz
fuzz testing
testing are
are completed
completed after
after system
system integration.
integration. These
These testing
testing
Lexmark’s
practices software
are part ofproduct
the development
normal continuousprocess
testingincludes static
philosophy analysis
otherwise. of the source code,
practices are part of the normal continuous testing philosophy otherwise.
where appropriate tools for that language are available. Alternatively, compiled “binary” code
Dynamic
Dynamic Application
scanning tools
Application Security
can be used to scanTest
Security (DAST)
Test (DAST) defects. This scanning is usually done
as part of the Lexmark development build pipeline, but the scanning tools can also be used
Lexmark’s
software product
product development
development process
process includes
includes verification
verification testing
testing using
using multiple
multiple
separately as part of an auditing or final security review process.
dynamic runtime analysis tools. Because of the wide variance in the types of software
developed by
The most widely
by Lexmark’s
used static
software teams
analysis (web
tools software,
throughout server-based
Lexmark’s software,
software embedded
development teams
developed Lexmark’s software teams (web software, server-based software, embedded
firmware); DAST
are the Coverity®
DAST tools
source
used by
code
by Lexmark’s
scanningLexmark
tool
development
and teams
the Veracode
teams throughout
binary code
firmware); throughout the organization, development teams utilizethe organization
scanning
a wide tool,
variety of
firmware); tools used Lexmark’s development throughout the organization
industry
include
though leading
but are
other 3rdlimited
not party DAST
task-specific to tools.
Acunetix,
static BurpSuite,
analysis tools Arachni,
may be Nextpose,
used when Nessus,
appropriate.and IBM Appscan.
include but are not limited to Acunetix, BurpSuite, Arachni, Nextpose, Nessus, and IBM Appscan.
Security-related
Lexmark has alsoissues found Black
integrated from these DAST tools
Duck OpsSight areour
into treated
build much the same
procedures as issues
to validate found
open
Security-related issues found from these DAST tools are treated much the same as issues found
by
by either software developers or by the SAST tools. Issues are evaluated by the architects us
source
either
andsoftware
license developers
usage of or by the SAST
components tools.
within our Issues areand
firmware evaluated byThis
security. the tool
architects
helps and
and
developers and
inventory our are ranked
software and
usage classified
and be awareperofthe
anyquality
updatesandrequired
and bug barby
bug bar requirements
updates. defined
developers and are ranked and classified per the quality requirements defined
during the planning phase of the development cycle.
during the planning
Security-related phase
issues of the
found fromdevelopment
these scans cycle.
are evaluated by the architects and developers
Any
and security-related issues thatper
are ranked and classified maptheto
toquality
the OWASP Top 10 are
requirements fixed during
defined and verified before the
the planning phase
Any security-related issues that map the OWASP Top 10 are fixed and verified before the
release
of the phase per the
development project’s quality and bug bar requirements.
cycle.
release phase per the project’s quality and bug bar requirements.
Any security-related issues that map to the OWASP Top 10 are fixed and verified before the
Fuzz
Fuzz Testing
Testing
Where
Where appropriate,
appropriate, Lexmark’s
software QA/test
QA/test process
process also
also includes
includes a
a specialized
specialized form
form of
of
Software
dynamic QA/Test Practices
to induce (verification)
dynamic analysis to try to induce program failure by introducing deliberately malformed or
analysis to try program failure by introducing deliberately malformed or
random data
data into the
the input channels of
of an
an application or
or program (Fuzz Testing). Software
random
While quality into input
assurance andchannels
system testing application program
are a continuous (Fuzz
part of Testing).
Lexmark’s Software
normal
where this is appropriate includes network protocol handlers, data stream interpreters, or
where thisdevelopment
software is appropriate includes
process network
and protocolthroughout
are performed handlers, data streamand
the design interpreters, or in
in
implementation
cases where human input may be acted upon and not merely recorded.
cases
phaseswhere
of thehuman input may
development be acted
project, someupon and
types of not merelycan
products recorded.
require additional security-
Lexmark
Lexmark uses
uses aa combination
combination of
nearer to the
of commercial,
commercial, in-house
end of the development
in-house developed,
developed, and
cycle. Such products
and manual
manual fuzz
fuzz testing
are those that
testing to
23WWM12325
to
contain independent
improve the subsystems
robustness of the that are independently developed and tested and then
software.
improve the robustness of the software.
lexmark.com
Automated Testing
7
8
Automated Testing
Where
Where appropriate,
appropriate, Lexmark
Lexmark uses
uses a
a combination
combination of
of both
both manual
manual and
and automated
automated testing
testing in
in the
the
Lexmark uses a combination of commercial, in-house developed, and manual fuzz testing to
integrated into a final complete system (e.g., printers and multifunction products). For these
Automated Testing
types of systems, security related verification testing practices such as dynamic, run-time
Where appropriate, Lexmark uses a combination of both manual and automated testing in the
analysis tools and targeted fuzz testing are completed after system integration. These testing
development and QA process. The use of automated testing allows teams to increase overall
testing efficiencies and to find problems earlier in the development cycle.
Dynamic
AutomatedApplication Security
testing is used Test
at various (DAST)
phases in the test process, including:
Lexmark’s software product development process includes verification testing using multiple
} Unit Testing
} Integration Testing
developed by Lexmark’s software teams (web software, server-based software, embedded
} System Testing
firmware); DAST tools used by Lexmark’s development teams throughout the organization
Source Code Controls
Lexmark has always focused on secure access to source code and release procedures. This
by either software developers or by the SAST tools. Issues are evaluated by the architects and
can include day-to-day activities as well as the onboarding and offboarding of developers. All
developers and are ranked and classified per the quality and bug bar requirements defined
code is maintained in a Code Management System that logs and tracks all code modifications.
Procedures for Source Code controls include validation for the following activities:
} Developer
release Onboarding
phase per the project’s quality and bug bar requirements.
} Developer Offboarding
Fuzz Testing
} Request Code Access
Where appropriate, Lexmark’s software QA/test process also includes a specialized form of
} Remove Code Access
lexmark.com
dynamic analysis to try to induce program failure by introducing deliberately malformed or 8
} Firmware
random Release
data into Process
the input channels of an application or program (Fuzz Testing). Software
where this is appropriate includes network protocol handlers, data stream interpreters, or in
} Software Release Process
Each of these procedures includes built-in monthly validation based on employee status, access
level required, and usage activity.
While we maintain internal controls, a large amount of focus is on the release process. In order
for Firmware to be generally available the following must occur:
Automated Testing
1. Firmware is digitally signed and encrypted by the build tools.
2. Customer-ready
development code is declared
and QA process. The use offrom all involved
automated groups
testing in operational
allows review.overall
teams to increase
3. Code is reviewed and signed off by United States (US) management.
Automated testing is used at various phases in the test process, including:
4. Code is uploaded to a secure location along with a secure hash for validation.
} Unit Testing
5. Code is promoted through internal procedures and file validation performed.
} Testing
6. Integration
Controller card is built with the new firmware and all file comparisons are validated.
} System Testing
7. IT Security runs ongoing hash comparison scripts once a quarter and archive results.
Software releases follow a similar path. This software includes all drivers, device management
software, print management software, and embedded solutions. The path for Software
includes:
1. Production code is declared from all groups involved in operational review.
2. Release checklist is reviewed by United States (US) management.
3. Request form is completed for posting.
} Developer Onboarding
4. Product is released through build procedures.
23WWM12325
5. Secure hashes are captured for audit purposes.

} Request Code Access
6. Notification is sent to Release Team, IT Security, and Lexmark personnel responsible for
lexmark.com
publishing and/or distributing to end users.
89
7. IT Security runs ongoing hash comparison scripts once a quarter and archives results.
4. Code is uploaded to a secure location along with a secure hash for validation.
5. Code is promoted through internal procedures and file validation performed.

6. Controller Development
card is built with theLifecycle
new firmware and all file comparisons are validated.
7. IT Security runs ongoing hash comparison scripts once a quarter and archive results.
Software releases follow a similar path. This software includes all drivers, device management
software, print management software, and embedded solutions. The path for Software
includes:
1. Production code is declared from all groups involved in operational review.
Dynamic Application Security Test (DAST)
2. Release checklist is reviewed by United States (US) management.
3. Request form is completed for posting.
4. Product is released through build procedures.
5. Secure
firmware); hashes
DAST tools are
usedcaptured for audit
by Lexmark’s purposes. teams throughout the organization
development
6. Notification is sent to Release Team, IT Security, and Lexmark personnel responsible for
publishingissues
Security-related and/or distributing
found to end
from these users.
DAST tools are treated much the same as issues found
7. IT Security runs ongoing hash comparison scripts once a quarter and archives results.
during
Releasethe Practices
planning phase of the development cycle.
Security-related practices that are performed during the release phase of the Lexmark
release
softwarephase per the project’s
development process quality
include and bug bar
activities requirements.
intended for final or near-final (function-
complete) versions of the software or firmware under development. These practices include
Fuzz Testing
a Release Security Review and may include Application Penetration Testing if this testing is
Where appropriate,
indicated Lexmark’s
in the security software
requirements QA/test process also includes a specialized form of
definition.
Application Vulnerability
random data into Assessment
the input channels of an application or program (Fuzz Testing). Software
where this istesting
Penetration appropriate includes
is simply network
an attempt protocol handlers,
to evaluate data
the security stream
of an interpreters,
application or in
or system
by safely trying to find and exploit unknown vulnerabilities in the system (i.e., ethical hacking).
Penetration
Lexmark testers
uses use a combination
a combination of manual
of commercial, anddeveloped,
in-house automatedand
hacking methods
manual to
fuzz testing to
systematically
improve compromise
the robustness an software.
of the application, server, network device or endpoint that is part of
the software or firmware system, attempting to gain access to the critical assets of the system
Automated
to Testing
impact their confidentiality, integrity, or availability. Once a vulnerability has been found and
exploited,
Where appropriate,
Development
the penetration
Lexmarktester
usesmay
Lifecycle
attempt to use
a combination thatmanual
of both compromise to launch subsequent
and automated testing in the
attacks against other parts of the
The system under test, or otherallows
systems on the
to network. Because
development and QA process. use of automated testing teams increase overall
of the “ethical
testing hacking”
efficiencies nature
and to of the testing,
find problems theinpenetration
earlier testercycle.
the development does not actually corrupt
lexmark.com 9
or otherwise compromise the assets of the system; they merely provide detailed documentation
about the vulnerabilities found and the exact methods used to exploit the vulnerability.
} Unit Testing
This type of testing is performed for software development projects whose security
} Integration
requirements Testingindicates the need for penetration testing. This penetration testing is
definition
performed
} SystembyTesting
an internal test team with penetration testing expertise and occasionally by an
independent firm that specializes in software penetration testing; or both in some cases.
Ideally, penetration testing is completed and the results are addressed prior to the release
of the software
Lexmark product
has always or feature.
focused However,
on secure accesswhen penetration
to source code andtesting is performed
release byThis
procedures. an
independent
can third partyactivities
include day-to-day it is oftenas
prudent
well asto perform
the the test
onboarding andonoffboarding
a released version of the All
of developers.
software
code due to theinfollowing
is maintained factors:
a Code Management System that logs and tracks all code modifications.
1. Independently
Procedures for Source testing a pre-release
Code controls includeversion mayfor
validation miss vulnerabilities
the induced in the final
following activities:
stages of implementation and testing.
2. The time it takes to initiate (bid, contract, develop a statement of work); configure
the test setup; perform the testing; and receive the test report for a full code-assisted
23WWM12325
} Request Code
third-party Access
penetration test can significantly impact the release timeline for software
products with shorter release cadences (e.g., quarterly releases).
lexmark.com 810
Release Security Review

independent third party it is often prudent to perform the test on a released version of the
software due to the following factors:
1. Independently testing a pre-release version may miss vulnerabilities induced in the final
stages of implementation and testing.
2. The time it takes to initiate (bid, contract, develop a statement of work); configure
the test setup; perform the testing; and receive the test report for a full code-assisted
third-party penetration test can significantly impact the release timeline for software
products with shorter release cadences (e.g., quarterly releases).
Dynamic Application Security Test (DAST)

Release Security Review
Prior to exiting the release phase of the Lexmark software development process, a Release
Security Review is performed to examine the overall product or feature’s security posture. The
goal of this review is to ensure that the appropriate practices in the SSDL have been properly
firmware); DAST tools used by Lexmark’s development teams throughout the organization
completed and to evaluate any remaining security-related issues that are above the minimum
acceptable level of security defined in the planning phase of the project and determine if they
can be eliminated, reduced, mitigated or accepted.
This review is performed by Lexmark’s security staff and the development teams involved in the
software development project.
Incident Response Process
Lexmark’s ultimate goal is to produce software and hardware that is free from security-related
vulnerabilities.
Fuzz Testing However, the sheer complexity of the code in the products results in the need
Fuzz Testing
to be able to address security-related issues in released products. Lexmark’s software and
hardware products contain hundreds of files, thousands of objects, and tens of millions of lines
of code and a product that was released with no known vulnerabilities may indeed have new
random data into the input channels of an application or program (Fuzz Testing). Software
vulnerabilities identified over time. This can be due to a previously unidentified vulnerability
found in custom code written by Lexmark, in a common shared system library, or in a third-party
library integrated into the Lexmark software or firmware.
Lexmark’s security staff and experts monitor multiple channels for the identification of new
security vulnerabilities including internal review, customer service, security-focused press,
security-related academic research, and technical alerts from organizations like NIST-National
Automated Testing
Vulnerability Database and US-Computer Emergency Readiness Team (US-CERT). Additionally,
Where appropriate,
Lexmark Lexmark
uses scanning uses a the
tools during combination of bothphase
implementation manual and
that automated
scan testing
source code in the
for out-of
development and QA
date or vulnerable process.
shared The use of automated testing allows teams to increase overall
libraries.
When new vulnerabilities are identified which might affect Lexmark’s products, they are
Automated
addressed testing
via Development
is various Lifecycle
used atprocess:
the following phases in the test process, including:
} Unit Testing
1. The vulnerability is analyzed to determine if it affects the product. (Vulnerabilities found
lexmark.com
} Integration Testingor third-party code libraries may not apply, depending on the way the
in shared system
10
} code isTesting
System used in the system).
2. Lexmark’s security staff determines if the exploit mechanism for the vulnerability is
possible in Lexmark’s implementation.
Lexmark hasto
3. If yes always focused
2, above, on secure
the security access
bug to source
is scored using code andstandard
industry release procedures.
Common This
Vulnerability Scoring Systems (CVSS). Note: The severity score published in a technical
code isalert
maintained in adifferently
may score Code Management
in specificSystem that logs and tracks all code modifications.
implementations.
Procedures for processes
4. Internal Source Code
arecontrols include
initiated to log,validation for and
track, patch, the following activities:
test the bug fix, and updated
} code is provided
Developer via a patch process.
Onboarding
5. Developer
} If the CVSS score warrants, Lexmark issues a security advisory for the products affected.
Offboarding
23WWM12325
When issued, Lexmark

} Request security advisories are posted on http://support.lexmark.com/alerts.
Code Access
Lexmark also offers a subscription service to notify subscribed customers when a security
lexmark.com
advisory is posted. Also available is the ability for someone to submit a potential vulnerability
8 11
or concern to our team. This submission form allows for direct communication with our subject
matter experts. We then follow our standard vulnerability process to assign severity and
alert may score differently in specific implementations.
4. Internal processes are initiated to log, track, patch, and test the bug fix, and updated
Lexmark Secure code is provided via a patch process.

Software Development Lifecycle
5. If the CVSS score warrants, Lexmark issues a security advisory for the products affected.
integrated
1. issued,
When The vulnerability
into a final complete
Lexmark is analyzed
security system
to determine
advisories(e.g.,
areprinters
if it affects
posted and multifunction
the product.
products).
(Vulnerabilities
For these
on http://support.lexmark.com/alerts. found
Lexmark also offers a subscription service to notify subscribed customers when a security the
types of
in systems,
shared system
security
or related
third-party
verification
code libraries
testing may
practices
not apply,
such depending
as dynamic,
onrun-time
the way
analysis
code
advisory toolsis and
usedtargeted
is posted. in theavailable
Also system).
fuzz testing are completed
is the ability afterto
for someone system integration.
submit a potentialThese testing
vulnerability
practices
or 2.
concern are part of the
to our securitynormal
team. This continuous
submission form testing
allows philosophy
for direct otherwise.
communication with our subject
Lexmark’s staff determines if the exploit mechanism for the vulnerability is
matterpossible
experts. in
We then follow
Lexmark’s our standard vulnerability process to assign severity and
implementation.
Dynamic Application
timelines for resolution. Security Test (DAST)
3. If yes to 2, above, the security bug is scored using industry standard Common
Vulnerability Scoring Systems (CVSS). Note: The severity score published in a technical
Conclusion
alert may score differently in specific implementations.
developed by Lexmark’s
Lexmark’s Secure software
Software teams (web
Development software,
Lifecycle server-based
process is a series ofsoftware, embedded
product activities
4. Internal processes are initiated to log, track, patch, and test the bug fix, and updated
firmware); DAST tools used by Lexmark’s development teams throughout the
designed to address various aspects of security as related to the Lexmark softwareorganization
code is provided via a patch process.
include but are
development not limited to Acunetix, BurpSuite, Arachni, Nextpose, Nessus, and IBM Appscan.
process.
5. If the CVSS score warrants, Lexmark issues a security advisory for the products affected.
Security-related issuesafound
This process provides from these
framework DAST tools
for designing are treated
enterprise muchand
software the same as issues
hardware found
products
by either
When
that software
issued,
are more developers
Lexmark
secure security
and or by
in the
the SAST
advisories
resilient are tools.
posted
changing Issues are evaluated
andbyisthe architects
on http://support.lexmark.com/alerts.
security landscape essential and
to meet
developers
Lexmark also
the security and are ranked
offers ofand
our classified
a subscription
requirements service per
customers. the quality
to notify and bug
subscribed bar requirements
customers defined
when a security
during the
advisory is planning phase
posted. Also of the development
available cycle.
is the ability for someone to submit a potential vulnerability
or concern to our team. This submission form allows for direct communication with our subject
matter experts. We then follow our standard vulnerability process to assign severity and
timelines for resolution.
Fuzz Testing
Conclusion
Lexmark’s Secure Software Development Lifecycle process is a series of product activities
designed to address various aspects of security as related to the Lexmark software
random data into the input channels of an application or program (Fuzz Testing). Software
development process.
cases where provides
This process human input may be acted
a framework upon andenterprise
for designing not merely recorded.
software and hardware products
that are more secure and resilient in the changing security landscape and is essential to meet
the security requirements of our customers.
Automated Testing
development and QA process. The use of automated testing allows teams to increase overall

© 2018 Lexmark. All rights reserved.
} Unit Testing
Lexmark and the Lexmark logo are trademarks or registered trademarks of Lexmark International, Inc. in the United States and/or other countries. All other trademarks are the
property of their respective owners.
} Integration Testing
lexmark.com
} System Testing

© 2018
23 Lexmark. All rights reserved.
23WWM12325
Lexmark and the Lexmark logo are trademarks or registered trademarks of Lexmark International, Inc. in the United States and/or other countries. All other trademarks are the
} Request
property of their respective owners. Code Access
lexmark.com 8

NA SSDL Overview

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NA SSDL Overview

Uploaded by

Copyright:

Available Formats

Lexmark Secure Software

Lexmark Security Training

} Fundamentals of Application Security

} Software Security Awareness

Security Engineering and Design

} Creating application security design requirements

} Performing a security code review

Secure Coding Practices

} Fundamentals of secure development

} Input and output validation

} Creating an Application Security Threat Model

} Attack Surface Analysis and Reduction

Security Testing and Assurance

} Fundamentals of Security Testing

} Application Penetration Testing

Product Planning and Design Practices

Security Requirements Definition

} OWASP Application Security Verification Standard (ASVS)

} SANS Securing Web Application [SWAT] Checklist

} CWE/SANS Top 25 (non-web applications)

} Application Security and Development Security Technical Implementation Guide (STIG)

Quality Gates/Bug Bars

Additional Security Practices

Design Requirements Definition

} Identification of the critical assets

} Identification of potential threats to those assets

} Determining the impact for each threat identified

} Determining the probability (risk) of compromise by an attacker

} Ranking of the risks

} Determining mitigating countermeasures as needed

Attack Surface Analysis/Reduction

Lexmark has also integrated Black Duck OpsSight

5. Secure hashes are captured for audit purposes.

5. Code is promoted through internal procedures and file validation performed.

Lexmark Secure Software

Release Security Review

Dynamic Application Security Test (DAST)

When issued, Lexmark

Lexmark Secure code is provided via a patch process.

Automated testing is used at various phases in the test process, including:

Source Code Controls

You might also like