Overview
This policy describes how Guido Pettinari, operating as an independent consultant, approaches secure software development when delivering software, automations, integrations, or technical implementations for clients.
It is intentionally lean. The operating model is that of a sole proprietor, not a large software vendor. The controls below are applied in proportion to the size of the engagement, the type of system involved, and the sensitivity of the data being handled.
Where an engagement is purely advisory and no software is built or operated, the sections related to development, testing, deployment, and maintenance apply only if those activities become part of the scope.
1. Security starts at design time
Security is considered from the beginning of a project, not only at release time.
Where applicable, this includes:
- defining security requirements early
- keeping access limited to what is actually needed
- avoiding unnecessary collection or use of sensitive data
- preferring secure defaults for authentication, authorization, and data handling
- identifying material risks before implementation
2. Development practices
Software is developed using standard engineering controls that reduce avoidable security mistakes.
These practices include:
- use of version control for source code
- code review before release, typically performed by the client's development team, supplemented by automated review tools
- avoiding hardcoded secrets in source code
- keeping dependencies and tooling reasonably up to date
- using reputable third-party libraries and services
- restricting access to code, credentials, and infrastructure to authorized accounts only
3. Environment separation
Where software development is part of the engagement, development, test, and production environments are kept separate and managed separately.
Real production data should not be used in non-production environments unless there is a specific need, appropriate authorization, and suitable safeguards.
4. Secrets and cryptographic material
Secrets, credentials, API keys, private keys, and other sensitive configuration values must be stored and transmitted securely.
The following rules apply:
- secrets must not be committed to source control
- access to secrets must be limited to the minimum necessary
- secure channels must be used for transmission
- rotation or revocation must be performed where applicable, for example after suspected exposure, personnel changes, or service migration
5. Authentication and access control
Access to systems and services used in delivery should be protected through strong authentication where supported.
This includes, where applicable:
- multi-factor authentication enabled on business-critical services and accounts
- unique accounts for named users
- least-privilege access
- prompt removal of access that is no longer needed
As a sole proprietor, some duties cannot be segregated in the same way they would be in a larger organization. Even so, privileged access is kept limited and used only where necessary.
6. Devices and working environment
Work is performed on supplier-controlled devices.
Reasonable endpoint and device security controls are maintained, including where applicable:
- device password protection
- screen lock after inactivity
- full-disk encryption (e.g. FileVault on macOS)
- regular operating system and application updates
- native operating system security protections and malware protections
7. Vulnerability management
Security issues found in delivered software are handled according to severity and business impact.
Where applicable, the response may include:
- triage and validation of the issue
- prioritization based on severity and exploitability
- remediation or mitigation
- communication with the client when the issue materially affects the delivered service
If a contract defines specific remediation timelines, those timelines take precedence.
8. Logging, monitoring, and incident handling
Relevant logs, platform alerts, and security notifications are reviewed where applicable in order to detect suspicious activity, unauthorized access attempts, and operational issues. Where appropriate, dedicated monitoring tools (such as error tracking and uptime monitoring services) are used to surface issues proactively.
If a security incident affecting client systems or client data is identified, it will be handled with appropriate urgency. This may include containment, remediation, investigation, and timely communication to the client when required by contract, law, or the nature of the incident.
9. Third-party services and cloud tools
Third-party services, cloud platforms, and software components may be used where appropriate to deliver the engagement.
When they are used, the selection should take into account:
- security posture
- access controls
- data sensitivity
- operational necessity
- client requirements
Where a client requires prior approval for particular tools, environments, or cloud services, that requirement will be respected.
10. Review and improvement
This policy is reviewed periodically and may be updated when there are material changes in working practices, tools, legal obligations, or client requirements.
Project-specific security requirements may supplement this policy where needed.
Reference basis
This policy draws on principles from public secure development guidance, including the OWASP Software Assurance Maturity Model (SAMM).